Regression, SpeedCrunch nightly takes 2-3 times longer to start up than v0.11

Issue #568 closed
Former user created an issue

This is a copy of issue 568 on Google Code.

Steps to reproduce: Install SpeedCrunch v0.11 Obtain SpeedCrunch nightly from https://github.com/Tey/speedcrunch-nightlies/tree/master/win32 I obtained version SpeedCrunch master-09d874ee223c0045556b2c7a307c36803dcea2aa Open SpeedCrunch multiple times so that the EXE gets cached into RAM. Time how long it takes to open. both the stable and nightly versions.

Expected behavior: both versions take same amount of time to open.

Experienced behavior: v0.11 takes less than 0.5sec on an Intel Core I5-750 CPU when using a stopwatch. v0.11 takes 0.17sec when using ProcessExplorer to see total CPU time.

latest nightly takes just over 1.0sec on the same computer when using a stopwatch. latest nightly takes 0.70sec when using ProcessExplorer to see total CPU time.

Product version: v0.11 and master-09d874ee223c0045556b2c7a307c36803dcea2aa

Operating system: Windows 7 64-bit

Additional Information: Ideally, launch time should be non-noticeable to a human. v0.11 launch time is fast but noticeable on my PC. Other small utilities such as notepad2 open faster but v0.11 launch time is good enough.

Latest nightly is painstakingly slow to open, to the point I sometimes start typing my math and the calculator misses the beginning if i don't move my head up to look at the screen and make sure it finished loading.

To compound this issue, using a shortcut to open latest nightly opens up a new instance, it doesn't bring current instance to front. This really slows input speed when pinging back and fourth between screens. I have just opened a different bug for the new instance regression.

Comments (5)

  1. Tey'

    Thanks for your feedback. I can confirm the issue, and it should be fixed for the latest builds.

    It's related to the way the nightly builds script packs the executable. In short, the size of the executable is a bit big (~14MB), so we compress it using UPX. This affects the start time, because the application first needs to extract itself into the memory before running (and caching does not help).

    The 0.11 release is also packed with UPX, but I used a different compression factor for the nightly builds (--brute). The build script now uses the same compression factor (--best), and the application start time is now almost the same as with the 0.11 release. If this is still too long for you, check the _raw version in the win32 subfolder: they are the non compressed version of the executable.

    Note that the nightly builds still rely on the GitHub repository, so there will probably be no new builds until I modify the script. Also, as Helder wrote on the Google code issue tracker, they are still experimental (but I use them at least).

  2. Log in to comment