BYE slow start up

[tjensen7817]

Recently BYE has been very slow to start. Once running, it seems fine. This is new behavior. I'm running Win 10 64 Bit with 6GB RAM.

Has anyone else noticed this? Is there a fix?

Thanks
Tim

[jimwc6491]

Rick, Guylain, tjensen7817

The changes that were made in v.3.1.17rc2. worked to give an indication that the program is booted.

thank you Guylain.

[astroman133]

What version are you running?

Guylain has said that there are changes that can be made to speed up BYE/BYN startup, but they are not yet released.

There is more information in this thread:

 

[admin]

Some of these changes are in 3.1.17 RC2.  You can download 3.1.17 in the pre-release download section.

[tjensen7817]

Thanks for the feedback. I'm currently running 3.1.14. Will download the newest version now.

Cheers

Tim

 

[astroman133]

Be sure to download it from the pre-release area

[astroman133]

Yes, but I would still like to be able to reduce the number of rows in a capture plan to further shorten the start up time.

[admin]

3 hours ago, astroman133 said:

Yes, but I would still like to be able to reduce the number of rows in a capture plan to further shorten the start up time.

<geek talk = ON>

That was actually not the issue after looking into it... well sort of.  The screen was repainted for each of the 100 rows as they were added... and this took more time as it went through the loop one by one with a repaint for each. 

To fix this I suspended the repaint in the control as they were added and the resumed the repaint only once all the 100 rows were added.  This reduced the amount considerably as only one paint event was fired.

In addition, I show the splash screen sooner in the start process.

</geek talk = OFF>

 

[astroman133]

Thanks for the geeksplanation! <G> It makes perfect sense. Primitive Windows/controls design is not very optimum if it takes a lot of time to paint and repaint controls that are not even visible yet! I am so used to working with WPF where I do not bind controls to data until the form is displayed. This spreads out the initialization of various U/I forms so performance seems a lot more leveled.

On my 3.4 GHz quad core i7 desktop with over 5 GB of available memory, it still takes almost 10 seconds before I see the BYE main window. To me it seems like there is still quite a bit of room for reduction of the startup time.

[admin]

Yes, 10 seconds it still to much.... but compared to the 20 to 40 seconds before on some PC I'm happy with 10 seconds for now.  Baby steps.

[AndrewS]

Did these changes make it into 3.1.17?

I'm still getting at least a 30 second boot time to the main window on a desktop with Windows 7 Pro with and i7-4770 and 16GB, running from SSD.  It is (not surprisingly) slower on my imaging laptop.

[admin]

Not in 3.1.7... but I've been working on this for the past 3 weeks... it turned into a major refactoring of the capture plan UI.  The next release should have some significant application load time performance to it.  Too early to tell how much but there will be a positive difference.

Regards,

[AndrewS]

Okay.  Thank you, Guylain.  Just wanted to make sure my system wasn't the problem.

[admin]

On 6/26/2019 at 3:42 AM, admin said:

Not in 3.1.7... but I've been working on this for the past 3 weeks... it turned into a major refactoring of the capture plan UI.  The next release should have some significant application load time performance to it.  Too early to tell how much but there will be a positive difference.

Regards,

I just released 3.1.18 RC1 in the pre-release download section.  Please try it and compare the load time, you should see a positive difference.

Regards,

[AndrewS]

I haven't had a chance to try it on my laptop, but the desktop startup time is substantially reduced.  It takes about 7 seconds, now. 

Thanks again, Guylain!

[admin]

1 hour ago, AndrewS said:

I haven't had a chance to try it on my laptop, but the desktop startup time is substantially reduced.  It takes about 7 seconds, now. 

Thanks again, Guylain!

That's great Andrew, what was the time before on your computer?

A little bit of background...

BYE/BYN is event driven, including camera property values change events.  In the plan sequence there use to be 100 pre-loaded lines.  Each line have 3 camera properties, shutter, Av, and ISO.  That was 300 events fired and captured by the plan UI control... that is not a big thing usually... but all 300 events received required access to the UI thread to update the pulldown values... and that was the performance hog issue.

To fix this I did a few things. 

1. I moved the event listener to the parent container control and updated all plan item rows at once, this brought down the event from 300 to 3.
2. I have removed the 100 pre-loaded rows in favor of a user option to add rows at runtime as needed (premium only, classic edition is fixed to 20 rows).

These 2 changes made a huge difference.  When the application is loading, pay attention to the splash screen... it says loading..., initialize capture plan..., initialize Frame&Focus..., initialize Planetary..., etc....

The second step, initialize capture plan..., is where all the performance gain is as a result of these 2 changes.

 

[AndrewS]

I initially had times around 30 seconds.  I ran the original 3.1.17 before installing the release candidate, and it was around 21 seconds.  I'm not sure why it was quicker, today, other than I've probably rebooted since then.  I tend to have a lot of things running, and way too many tabs open in Chrome.

As I said, the RC was 7 seconds, but after exiting and running again, it's now taking about 4 seconds.

My laptop is quite a bit slower than my desktop PC, but I have not doubt this will also be a huge improvement, there.

I appreciate the detailed explanation of the changes.  I'm a programmer, so it's always good to hear of optimization methods.