Faster loading

[Darmok]

When launching Girder with a lot of commands, a couple hundred, it seems to take quite a while, maybe 20 seconds or so on a resonably fast PIII 850. What are some tips to speeding this up? Is there a way to open the same command with multiple inputs instead of having to copy the command over and over? Also is a goto command more efficient than repeating a single command? Will disabling groups until they are needed increase the time to load up the program...etc?

[Ron]

I've been thinking about this problem the last couple of days. The loading routines where written for compatibility but have not yet been optimised.

I have exams until saturday, after that i'll implements some speedups into the code. I have some ideas how to go about that.

All commands should take about the same time to complete. The loop overhead that is.. then it depends how fast the actual action is but the overhead stays about the same.

Dis/Enabling command won't make loading faster.

so just hang in there for a few days.

-Ron

[Ron]

If gave the source a quick profiling and I found out something that i'm not happy about at all. The reason the loading is this slow is because the treeview is terribly slow. Its not in my code.

I'm looking for a better treeview to replace the current one, but this can take some time as i have to evaluate several different controls and then buy the best one.

If anyone knows of any good replacement Treeviews don't hesitate to post that here.

-Ron

[Darmok]

Someone mentioned in another post that it would be nice to basically compile a Girder command list. Something like that should load very fast, and the slowness of the Treeview would be less important if its only slow on opening when editing the settings. Just a thought.

[Ron]

That would require a complete rewrite of the Girder core, because the datastorage is done in the tree. In hindsight that was not a too good idea. I'm currently about 2 hrs away from a big exam and tomorrow another so I didn't have to much time to find a replacement for the treeview. But I'm working on it...

-Ron

[Ron]

Good news people! I've found a replacement (yeah yeah i know ive got a exam 1 hour and 45 minutes) I've dropped that in and the load time went from 7 seconds to 100 milliseconds for 500 actions. If i get this control to work properly I'll buy it and have it in for version 3.0.22

-Ron

[Darmok]

Thats Great! Thanks Ron.

[Ron]

Please try out Girder 3.0.22 pre 3, this includes the new treeview in shareware
mode. Thus a nag screen will appear when you exit Girder, but the important thing is for me to know if it is worth to buy it so test it and give me some response!

-Ron

[SteveV]

Excellent news!! Thanks Ron!!!!!

Regards -- Steve

[Darmok]

It loads much faster now! It doesn't seem to store the enabled/disabled setting though. If they were set to disabled before this version was installed, they will still be disabled. But if I try setting something to disabled now. It enables it again as soon as I click out of it. I just started testing it, I'll look to see if I find any other problems. The speed increase is great though.

[Darmok]

Hmmm this is strange, I figured something else out about the enabled disabled. Whatever state the command you were previously on will copy set the state of the command you are currently on. IE if you click on a disabled command, and then click on an enabled command, the disabled command becomes enabled. This works the other way around too, so its just setting the previous commands state to the current commands state.

[Darmok]

Here is another one. When using the if window exists command when I browse to which command I want it to perform if the window does not exist, it comes up with a completely different command than the one I chose. When I looked through the girder file I figured out why, somehow the new command that I had made(which I was trying to choose) had the same identifier number as the other command(the one which was coming up instead). They both were identifier #392. I'll try to run through it and see if I can find any other bugs, but if its not too difficult to fix these, I think the speed makes it worth while.

[Ron]

Darmok,

Thanks for the bug reports, I was expecting this kind of odd behavious as the select/focus method of the new tree is a little different.

The fact that 2 commands have the same number is not good at all. I'm looking into it now.

-Ron

[Darmok]

I don't know if this helps but one of the commands was made a couple of days ago before I updated, and the other was done afterwards. I'll look to see if there are any other duplicates.

[Ron]

I've bought the control and I'm now working on a new release. I hope I have something for you all tonight!

-Ron

[Darmok]

It looks like the new release fixed the disabled/enabled problem I was running into. Did you find the problem that caused the commands to have the same identifier? If its fixed, can I fix the problem in my file by copying the commands and deleting the originals to get new identifiers?

[Ron]

Hi Darmok,

Copying should work yes. You could also open the gir file and edit the offending identifiers by hand. But this is ofcourse only an option if the file isn't to big.

Btw, i've seen that import is broken in pre-4 so you might want to stay away from that function, until the next release. :-(


-Ron