Improve Performance of UI

[Michael C]

Anyone have any hints on improving the performance of C# UI? I'm filling a
TreeView and ListView with information returned by a SQLDataReader and
information read from the Registry. I'm working on improving the SQL Query
execution speed, but have no idea how to improve Registry-reading
performance or TreeView/ListView update speed. Any ideas appreciated.

Thanks,
Michael C.

 

[Jon Skeet [C# MVP]]

Anyone have any hints on improving the performance of C# UI? I'm filling a
TreeView and ListView with information returned by a SQLDataReader and
information read from the Registry. I'm working on improving the SQL Query
execution speed, but have no idea how to improve Registry-reading
performance or TreeView/ListView update speed. Any ideas appreciated.

Well, are you already doing the SQL/Registry querying in a separate
thread, and updating the TreeView/ListView within BeginUpdate/EndUpdate
sections? Those would be the first things to do.

 

[Frans Bouma [C# MVP]]

Anyone have any hints on improving the performance of C# UI? I'm filling a
TreeView and ListView with information returned by a SQLDataReader and
information read from the Registry. I'm working on improving the SQL Query
execution speed, but have no idea how to improve Registry-reading
performance or TreeView/ListView update speed. Any ideas appreciated.

I'm not sure how big the dataset is but what really helps is not completely
filling the tree at once but per node, when they're expanded. This means that
you cache the data in a dataset or other bucket and add the child nodes to
the expanded node when the user expands a node.

Very easy to do and very efficient. Explorer for example does this too, it
would take ages to fill hte complete tree at the left.

Add a dummy node to every node which should have childs (and remove that
one when you expand the node) to be able to click it open.

FB

 

[Michael C]

The BeginUpdate/EndUpdate I'm doing - although it doesn't seem to speed up
the UI any, it does seem to reduce flicker. I'm working on splitting out
the SQL/Registry querying in a separate thread right now, but there might be
a little problem with that. Do you know, if you were to issue a
long-running Non-Query command against a SQL Server, could it cause problems
if the program was terminated in the middle of command execution?

As an example, if you issued a "DROP INDEX 'table1.idx_index1'" command that
was taking 15-20 seconds to run, and in the middle you ended the program
could it cause database inconsistencies? Or would SQL Server keep chugging
along and complete the request? I want to find an answer on this before I
put my non-query SQL commands on separate threads.

Thanks,
Michael

 

[Michael C]

One of the problems is that I don't know in advance how big the dataset is
either I'm testing all my code against two datasets - one we consider
"average" and a much, much larger one. I do have a well-defined structure
for my TreeView though, so I know exactly how many levels deep it needs to
be and exactly how the data will be grouped together. The dynamic node
filling is a very good idea. I'll have to work out some of the kinks as far
as 'synchronizing' (if that's the right word) the TreeView population with
the SQL queries on their separate thread.

I'm also playing with the idea of creating a new subclass or two of TreeNode
that expose some more properties I can use to get my SQL queries and node
fills in sync with one another. One property I'm working on is a "Level"
property that tells you which level a particular TreeNode is on - for
instance, the root node of the TreeView would be Level 0, it's immediate
children would be Level 1, etc., etc. What I've come up with as far as a
function is pretty useful, but I definitely don't want to re-invent the
wheel - is there a function or property out there that does this already?

All this brings up one more question (I'm about to test this myself) - do
you have to cast a subclass of TreeNode back to (TreeNode) in order to work
with it in a TreeView?

Thanks for the help,
Michael C.

 

[John Baro]

One of the problems is that I don't know in advance how big the dataset is
either I'm testing all my code against two datasets - one we consider
"average" and a much, much larger one. I do have a well-defined structure
for my TreeView though, so I know exactly how many levels deep it needs to
be and exactly how the data will be grouped together. The dynamic node
filling is a very good idea. I'll have to work out some of the kinks as far
as 'synchronizing' (if that's the right word) the TreeView population with
the SQL queries on their separate thread.

I'm also playing with the idea of creating a new subclass or two of TreeNode
that expose some more properties I can use to get my SQL queries and node
fills in sync with one another. One property I'm working on is a "Level"
property that tells you which level a particular TreeNode is on - for
instance, the root node of the TreeView would be Level 0, it's immediate
children would be Level 1, etc., etc. What I've come up with as far as a
function is pretty useful, but I definitely don't want to re-invent the
wheel - is there a function or property out there that does this already?

I use the ComponentOne flexgrid in treeview mode. It has a level property of
a node which is as you described(not that this helps you)
I cannot find anything in the standard ms treeview.

All this brings up one more question (I'm about to test this myself) - do
you have to cast a subclass of TreeNode back to (TreeNode) in order to work
with it in a TreeView?

No.
Upcasting is performed implicitly.

HTH
JB

"Upcasting" Casting to a base class.
Personally I've always called it downcasting because the "base" is always on
the bottom, but from a hierarchical perspective, upcasting fits better. (See
later thread in this group

Thanks for the help,
Michael C.

I'm not sure how big the dataset is but what really helps is not completely
filling the tree at once but per node, when they're expanded. This means that
you cache the data in a dataset or other bucket and add the child nodes to
the expanded node when the user expands a node.

Very easy to do and very efficient. Explorer for example does this

too,

 

[John Baro]

The BeginUpdate/EndUpdate I'm doing - although it doesn't seem to speed up
the UI any, it does seem to reduce flicker. I'm working on splitting out
the SQL/Registry querying in a separate thread right now, but there might be
a little problem with that. Do you know, if you were to issue a
long-running Non-Query command against a SQL Server, could it cause problems
if the program was terminated in the middle of command execution?

As an example, if you issued a "DROP INDEX 'table1.idx_index1'" command that
was taking 15-20 seconds to run, and in the middle you ended the program
could it cause database inconsistencies? Or would SQL Server keep chugging
along and complete the request? I want to find an answer on this before I
put my non-query SQL commands on separate threads.

SQL server would keep "chugging" away until it finishes as the query/command
is "sent" to the server which then queues it and processes.

HTH
JB

Thanks,
Michael

 

[Jon Skeet [C# MVP]]

The BeginUpdate/EndUpdate I'm doing - although it doesn't seem to speed up
the UI any, it does seem to reduce flicker. I'm working on splitting out
the SQL/Registry querying in a separate thread right now, but there might be
a little problem with that. Do you know, if you were to issue a
long-running Non-Query command against a SQL Server, could it cause problems
if the program was terminated in the middle of command execution?

If it did, I'd consider that a major flaw in SQL Server!

As an example, if you issued a "DROP INDEX 'table1.idx_index1'" command that
was taking 15-20 seconds to run, and in the middle you ended the program
could it cause database inconsistencies? Or would SQL Server keep chugging
along and complete the request? I want to find an answer on this before I
put my non-query SQL commands on separate threads.

I expect it would implicitly roll back the transaction, but I couldn't
say for sure. It certainly shouldn't screw up the db.

 

[Michael C]

Thanks all for the help! I'm definitely going to put some of this to work
in this app!

Michael C.