Fatty programs - we study the factor of memory part B

In the previous article, Fat-rate-speed programs were outlined on the subject - why programs “slow down”.

The memory factor was highlighted as important, but there were no ideas for testing its “fat content” depending on the framework. And so, having accepted a quiet, correct state on holidays, I generated such an idea.

A utility was written that allows you to measure the load time of the program and the associated costs - disk I / O and memory consumption. Link at the end of the article.

Some tests under the cut.

Take three similar programs - mini-IDE, written in different languages ​​respectively and using different frameworks - in the table

Each program is tested after the virtual system is loaded - we measure the time of the first and repeated starts. Virtual machine configuration - pure Windows 7, 1Gb of memory (340MB is used for the needs of the OS), 2 cores. The host is i5 3.2GHz, 8Gb of memory.

Test 1 - time to open a window and start a message queue

Enjoying Starting Time. After running, the stime utility every 3 seconds displays statistics on memory and disk input to output (page faults), which allows you to monitor the dynamic loading of the framework modules.

stime.exe "C: \ Program Files \ Notepad ++ \ notepad ++. exe"
DiskIO: 15.922MB WorkingSetSize: 13.613MB PagefileUsage: 7.5117MB
Starting time is 1333.03 ms, Restart: 196.751 ms

stime javaw -jar D: \ Downloads \ drjava-beta-20160913-225446.jar
DiskIO: 96.953MB WorkingSetSize: 72.559MB PagefileUsage: 82.148MB
DiskIO: 103.76MB WorkingSetSize: 73.621MB PagefileUsage: 91.965MB
Starting time is 5963.89 ms, Restart: 4541.6 ms

stime.exe -splash "C: \ Program Files \ SharpDevelop \ 5.1 \ bin \ SharpDevelop.exe"
DiskIO: 85.934MB WorkingSetSize: 54.414MB PagefileUsage: 45.117MB
DiskIO: 136.74MB WorkingSetSize: 71.609MB PagefileUsage: 66.969MB
DiskIO: 137.43MB WorkingSetSize: 72.09MB PagefileUsage: 67.035MB
Starting time is 7863.89 ms, Restart: 1405.49 ms

A slight incorrectness with the start time was noticed - time is detected by the function that controls the start of processing the message queue - but some programs, for example DrJava, start processing it in the background, although the download is still very long.

Therefore, for Java, a workaround is used - we expect additionally the appearance of a visible window with a non-empty header.

Similarly, for SharpDevelop, waiting for the creation of the main window and suppression splash is enabled by a special option. And even after the appearance of the main window, SharpDevelop still decently loaded - as can be seen from DiskIO 3s after the start.

Another interesting point is that when the virtual machine was configured with a single-processor one, Java boot times tripled (~ 35c), for C ++ and .NET programs, this did not affect.

Test 2 - time to load the source code file and work out the exit command

When launched with the -quit option, the stime utility immediately after starting the child process sends a command to close WM_QUIT. Enjoying Full run time - serif on process unloading from memory.

stime.exe -quit "C: \ Program Files \ Notepad ++ \ notepad ++. exe" stime.cpp
DiskIO: 16.734MB WorkingSetSize: 14.32MB PagefileUsage: 8.0664MB
Full run time is 1611.67 ms, Restart: 240.524 ms
')
stime.exe -quit javaw -jar drjava-beta-20160913-225446.jar JsonIterator.java
DiskIO: 97.992MB WorkingSetSize: 75.52MB PagefileUsage: 100.41MB
Full run time is 6860.405 ms, Restart: 4533.613 ms

stime.exe -splash -quit "C: \ Program Files \ SharpDevelop \ 5.1 \ bin \ SharpDevelop.exe" kernel.cs
DiskIO: 127.4MB WorkingSetSize: 68.148MB PagefileUsage: 53.133MB
Full run time is 9752.181 ms, Restart: 3066.784 ms

Here, too, we have to apply a workaround for Java - after the application window has closed, we target javaw.exe

→ Sources of stime and binary on GitHub

Conclusions - loading the framework is a very expensive operation, since it costs a lot of random I / O. Want a quick program - make it compact means.

Well, for detailed diagnostics, we forget about the more detailed utilities of Russinovich and the profiling tools for his set of tools.