Navigation
RSS Feeds
Slow FIRST Start After Boot for Komodo Edit
Posted by kleinfelter
on 2007-02-13 12:37
OS: Windows XP Pro
Komodo Edit takes 30 seconds to start, the first time I start it after a reboot. Otherwise it takes 2 seconds.
What is different between the two, and what can I do to get that first start closer to 2 seconds.
I'm running Komodo Edit, version 4.0.0-beta5, build 274646, platform win32-x86.
TIA
- Login to post comments
Typically Komodo should only be slow on the first start after it has been installed. It should not make any difference between reboots. After the initial startup, it should always be more like the "2 seconds" you mentioned.
Note: One other factor that influences the startup time is running the IDE 4.0 version between Edit runs, as this will also make the next startup of Edit slow (it needs to reset the internal component registration). This IDE/Edit conflict will be fixed in GA release of Komodo Edit (check ftp.activestate.com for updated builds).
Could that be what you experienced?
Thanks for your reply.
What I just now tested is:
0. Run Komodo and disable auto-loading of start page or old files.
1. Reboot
2. Login and wait until CPU use goes to 0%.
3. Run Komodo -- takes 30 seconds to be responsive to input.
4. Exit Komodo.
5. Check Task Manager to see that Komodo.exe is no longer running.
6. Run Komodo -- takes 2-3 seconds to be responsive to input.
7. Exit Komodo.
8. Check Task Manager to see that Komodo.exe is no longer running.
9. Run Komodo -- takes 2-3 seconds to be responsive to input.
10. Exit Komodo.
11. Check Task Manager to see that Komodo.exe is no longer running.
12. Reboot
13. Login and wait until CPU use goes to 0%.
14. Run Komodo -- takes 30 seconds to be responsive to input.
15. Exit Komodo.
16. Check Task Manager to see that Komodo.exe is no longer running.
17. Run Komodo -- takes 2-3 seconds to be responsive to input.
18. Exit Komodo.
While I'm waiting the 30 seconds, Komodo is consuming 20-30% of CPU, and there's lots of disk activity. I tried disabling my anti-virus, thinking that perhaps it was scanning the exe on the first load after boot, but disabling it did not improve the 30-second load after reboot.
Any more ideas? Is there any sort of logging I can turn on in order to see what it is doing?
TIA
I was just testing this before as well, and found much the same results.
It's not to do with the forementioned component registration problem, so I'm investigating more at present...
If you are using Windows you can use the utilities from http://www.sysinternals.com
filemon and process explorer
to monitor Komodo on startup
If using filemon utility, set the keyword .. Komodo .. in the filter INCLUDE field
and in filter EXCLUDE field add the processes which you do not wish to include in the report ..
e.g. mine is typically ..
vsmon;explore;zlclient;firefox;ccEvtMgr;SPBB
Just go to task manager and insert in EXCLUDE field the running process names.
...
Then you can compare your filemon reports (they will be large so you might need a script to find differences).
...
In process explorer (which can run at same time as filemon) go to View > System information to inspect Komodo CPU usage, and you can view DLL / Handles used by Komodo.
Good suggestion. FileMon shows that the slow version does quite a bit more file I/O -- no surprise there.
Some of the I/O is reading DLLs under C:\Program Files\ActiveState. ListDLLs does not show those DLLs as remaining resident after exiting KE, so my guess is that Windows is secretly caching them.
Just scanning through the logs, the big thing that leaps out is a run of about 450 reads of C:\Documents and Settings\kevin\Application Data\ActiveState\Komodo\4.0\host-win2k\XRE\XUL.mfl in the slow start. It only accounts for a couple of seconds, but 450 reads certainly stand out.
The other thing I notice is that in the fast start, there is a big string of QUERY_INFORMATION calls on language folders under "C:\Program Files\ActiveState Komodo Edit 4.0\lib\mozilla\extensions".
In the fast start, it is just a sequence of QUERY_INFORMATION, checking ...\plugins, ...\platform\WINNT\plugins, and ...\platform\WINNT_x86-msvc\plugins (and also for 'components' subdirectories). In the slow start, after each check of WINNT_x86-msvc, it also does 3 successful READ C: calls.
In fact, this is a pattern that shows up in several places, where the fast load does QUERY_INFORMATION and the slow load does READs after the QUERY_INFORMATION.
Well, now I have a lot more data, but no more understanding. The slow start does roughly 3x more I/O than the fast start, but I already knew that from watching the disk IO LED.
Good analysis, yes it's likely to do with the file caching.
The initial slow read of "450" seconds is likely for reading the Komodo.jar file, which contains all the UI information for Komodo.
I would hazard a guess that due to Windows keeping a cache of files around (or page file information), it is thus subsequently much faster the second, third times and so on...
Does your firefox/thunderbird applications show the same symptoms?
Isn't this just the typical cold start vs. warm start issue that affects any application that loads a lot of libraries and files into memory?
After a reboot the system will not have any of Komodo's libraries in memory and its takes time to load them. When re-starting Komodo after recently closing it, a lot of Komodo's libraries will not have been paged out of memory so the time isn't needed to load those from disk into memory.