In addition to checking on the impact this would have on an older machine, it would be useful to check the impact on a more recent machine that's already set up to preload or automatically launch a bunch of stuff at boot. (In reply to Eric Shepherd from comment #7) I would argue that it feels more frustrating to have two long waits than one longer wait and one short wait, if that makes sense. I.e., they would wait 2 minutes for their machine to start up and 5 seconds for Firefox to start up, rather than 1 minute and 55 seconds for their machine to start up and 10 seconds for Firefox to start up. ![]() If Firefox is always the first application a user opens, then it still makes sense to run this, since in the worst case it still consolidates the time that the user is waiting. However if it does impact that measure then we need to have subtler conversations, and I think it will depend on exactly how much impact we're having on overall startup vs how much benefit we see for Firefox startup. If it doesn't impact that measure then I think it's likely we could put the question to bed. I haven't sorted out a good way to measure this yet - one idea might be to have the machine open, say, MS Word right after startup and measure the time taken from power button pressed to a Word window open. Yeah, outside of this bug I've had a few conversations about that, and that's a large part of what I'm talking about when I say "we need to figure out all the implications of doing this." For one, I want to measure the impact that this has on the time until the machine is started up and basically usable. It reminds me of the "quick starters" that larger apps like OpenOffice used to have (although those remained resident). Especially on low-end computers, the first couple of minutes after startup are especially painful, and implementing this for Firefox will only contribute to that. Is this really a good idea? Warming a cache at startup seems to save 5 seconds or so of IO and makes Firefox appear to start faster.īut on the other hand, that's some 5 seconds of IO that's taken away from the rest of the system. (In reply to Laurentiu Nicola from comment #5) There is some overlap across processes, but a single process registers 52 seconds in ReadFile, which is certainly longer than it took to start up but right around the duration of the recorded interval. xul.dll registers a total of around 120 seconds in ReadFile, which is longer than the interval that I'm recording. I'm going to at first try the LoadLibrary approach though and see if it cuts the time down any. However, this sounds to me like it might have security implications. In that case, I would need to make the service call LoadLibrary on the dll files rather than simply mapping and reading the file. I'm wondering if windows handles the caching of files loaded as libraries differently, caching some processed form of it rather than the raw file contents. However, after launching firefox, it seems like that cache entry is blown away, and a new one using only 44KB is there in its place. After OS startup, before launching Firefox, RAMMap shows xul.dll as being in the cache, using up 100KB, which is the size of Nightly's xul.dll. In any case, I ended up taking a look at RAMMap's measures of things to get an understanding. Unfortunately it really doesn't seem to cut down on the cost of reading xul.dll, which seems to be the biggest offender if I'm reading Procmon's durations right. The results weren't night and day, but there may have been an improvement. ![]() ![]() I created a simple service to test this which just maps the file to memory and reads a byte from every page.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |