|
|
@Petr: Is it possible for the two utility processes use MediaMonkeyEmbedded.exe (just 1.2 MB) instead of MediaMonkeyEngine.exe (28 MB) ?? This should reduce startup time significantly. Zvazdan's logs in private note ~75891 |
|
|
Cleared Portable folder with empty db, Home screen displayed on start, time to show up + time when it was responsive to open a menu: - without DebugView - 13 + 3 seconds; - with DebugView - 23 + 14 seconds. |
|
|
Debug output times improved in 3031, left assigned to Petr to optimize JS loading times (by having all JS files in a single ZIP) |
|
|
As requested here are my test steps: 1. Download https://www.passmark.com/products/apptimer/ 2. Setup AppTimer According to PIC1 (Paths to EXE and LOG files May Differ according to your system) 3. Use RUN APP to measure RUN time Repeat 1-3 process with DBGview started (change LOG file name in order to have both logs) Test Note: Used /nosplash command line as Splash screen have same Window name as main app and influence the result No DBGview: 21.5921 (27.26 till first mouse click was executed in Main MM screen [clicked on Menu]) With DBGview: 21.2235 (34.19 till first mouse click was executed in Main MM screen [clicked on Menu]) EDIT: Clean portable Same results, but after few starts Windows prefetched/cached exe so it is lowered to 11.3568 (14.78 on menu click) without DBGview Started. NON debug EXE starts in <10s PIC1.jpg (42,767 bytes) |
|
|
Can you recheck with 3031. I have found the reason for me. Ryzen Master said my CPU and Motherboard was set to CPU AMD ECO POWER SAFE MODE After Firmware update, this resulted that only 8 of 24 CPU cores work I have reset Factory Defaults for MB and CPU now MM starts normally. C:\MediaMonkey 5\MediaMonkey.exe - 1 executions 5.0256 |
|
|
In 3031 the startup debug ouput was reduced a lot so that running DbgView is not slowing MM start so much.. But I have found that the most significant slowdowns are caused by compilation with Eureka, even debug builds that are compiled without Eureka are fast enough.. So it is about optimizing Eureka (some Eureka settings like disabling "range checks" or "overflow checks" https://docwiki.embarcadero.com/RADStudio/Athens/en/Compiling ) @Zvezdan / @Peke: I wonder what's your start time with non-debug builds? |
|
|
@Peke - thanks for the info about AppTimer, but I am just wondering, how did you get the time till first mouse click was executed, even so on the second decimal? |
|
|
Here are my new tests. I tested 3029 again because I wanted to compare them in the similar conditions. I did the previous tests with the system running about 120 days without restart, only hibernation, so maybe it had something related to the fragmented memory. I made these new tests a few days after restart. All tests with the Home view, unless one test with Folders. Many tests are with the Maximum processor state set to 99%, because the fan in my laptop could be annoying on 100%. Averaged values after at least 5 measuring with the same version/condition. 3029 - debug (99%): 22 sec (29.6 sec for opened menu) 3029 - no debug (99%): 11.2 sec (12 sec) 3031 - no debug (99%): 11.3 sec (12.2 sec) 3031 - no debug (100%): 6.4 sec (7.3 sec) 3031 - debug (99%): 15.2 sec (18 sec) 3031 - debug (99%, folder 30 albums, 229 files): 14.3 sec (29.3 sec) 3031 - debug (100%): 8 sec (7.7 sec) 3031 - release (100%): 2.3 sec (3 sec) 3031 - release (99%): 3.9 sec (4.5 sec) So, the 3031 with DebugView is significantly faster than 3029. For example, it is 18 sec vs 29.6 sec for 99%. They are quite similar without DebugView. |
|
|
ok, so debug messages reduction during startup helped, it is still quite surprising that 99% is twice slower than 100% Anyhow further tweaks to Eureka compilation should improve it further.. Some tips: https://support.eurekalog.com/Knowledgebase/Article/View/92/0/7x-my-application-runs-very-slowly-with-eurekalog |
|
|
@zvezdan re 0021013:0075992 This time I had phone running stop watch next to top left of monitor, then recorded Slowed motion video (240 frames a second) with my other phone, and once menu opens I written the time on the phone and deduct time start time when I clicked on run app in AppTimer. Usually I use Hardware recording (AMD GPU), but driver was quirking recently and would not want to use recording to RAM Disk. After I done resets my RAM timings and put CPU into High performance I get results same as @Zvezdan for Release builds on clean Library and 3-4 Average on my full library and entire library -> all tracks -> list view (10k+ of tracks). NOTE: After few MM restarts Windows prefetch EXE file and it partially loads from memory dump so I get 1.750 - 2.180 startup time to empty Playing view. |
|
|
Further findings are that using ecc32speed.exe post-compiler does the trick to make it much faster: https://www.eurekalog.com/help/eurekalog/index.php?post_process_compilers.php So we might want to try ecc32speed.exe instead of ecc32.exe for the next builds.. |
|
|
Fixed in 3032 |
|
|
re Verified 3039 Non debug: <2s Debug build: around 3s (varies from start to start) and <5s with DBGView opened. |
- Anonymous
