+1, when working on startup performance, I had a really difficult time following the startup sequence from the code. I actually relied more on the generated traces to know what was going on. Additionally, since nothing was commented, and all ordering seemed arbitrary, it was hard to tell if things were scheduled at a certain place for a reason, if the could be moved around to help startup perf, etc.
It would be great at least if every piece of initialization code could have a comment that states what it's initializing, and what it depends on having been already initialized, etc. This would then help the second pass of moving the minor initialization where scheduling isn't important into better places... It is also probably currently a mess for cross platform, for example, we were initializing winsock in browsermain, which to me seems completely unrelated to this portion of code. On Wed, Jan 14, 2009 at 9:11 AM, Peter Kasting <[email protected]> wrote: > On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) <[email protected]> > wrote: >> >> It looks like everyone and their dog adds init code to the startup >> sequence. This takes the form of first time initialization, command >> line switch parsing, etc. Is there any special reason why it's done in >> the startup flow vs. in a static method the first time a service is >> created or used? > > All I know is there are lots of ordering dependencies, where certain classes > must be initialized before others. Most of these are subtle and > undocumented :( > Even besides the methods you named, there are a slew of other initialization > methods whose purpose is wildly unclear. When adding support for > --user-agent=, I tried to understand some of this stuff better with jam's > help and came to the conclusion that a lot of it was insane and should be > condensed, redesigned entirely, etc. If you're cleaning up startup, > definitely also look at the methods I touched when adding that switch too (a > lot of them might be better places for stuff that lives in BrowserMain). > PK > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
