I'm not coming at this from an optimization perspective, I'm thinking more of making the startup flow understandable to mere mortals. Sadly the sequence now is complex enough that people are jamming in their init code wherever because by all appearances that's what everyone else has done. I suggested moving init to the components just because it'd group the init code with the code being init'ed.
Another option would be to do something like how Browser prefs are initialized and have functions that do all the init steps with understandable names, then it'd be clearer where to add your code. A less effective option IMO is to add comments, since the files are so long I'm not convinced people entering from one place will read a comment somewhere else in the file. -Ben On Thu, Jan 15, 2009 at 8:55 AM, Jim Roskind <[email protected]> wrote: > IMO, the big grouping distinction for startup code is a) code that needs to > be performed while single threaded; vs b) code that can run while > multi-threaded. > The first group effectively replaced the Google-style-illegal global static > initializers, and allows slight variation of ordering between startup and > shutdown as necessary. It is a shame that some items are just "put" into > this group without an explanation of dependencies ("...must come before X > and/or must come after Y"). > For best performance, I don't believe lazy initialization is a win when a > large group of resources all must *definately* be initialized before some > key point. I believe that better absolute throughput can be achieved by > prescheduling, but at times, we're lazy, and lazy initialization serves us > well enough. > Although I think it would be premature optimization to insist on either > approach (all lazy, or all sequenced), I think it would also be premature > deoptimization to insist on either. I think we'll end up with both, and so > I'd rather see authors make their best guess at optimality (including ease > of implementation and performance). > ...but it sure would be nice to list dependencies (if not assert/DCHECK) so > that folks have a fighting change of moving stuff around and optimizing! > Jim > > 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? >> >> I think moving a lot of this stuff out of the following places: >> >> BrowserMain >> BrowserInit::LaunchWithProfile::Launch >> BrowserInit::LaunchBrowserImpl >> >> ... might make the startup flow easier to understand. As it stands, >> there's first-time init code for various services sprinkled across >> these methods and it's not clear why they are done in one function and >> not another - since there aren't any explanatory comments it seems a >> case of "i'll just shove this here for now". >> >> It seems like adding some phase notifications here might also help. >> >> Also, does anyone know why BrowserInit::MessageWindow is inside >> BrowserInit? It seems to be only used by BrowserMain. BrowserInit is >> higher level and has to do with the creation of the initial set of >> browser windows. >> >> -Ben >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
