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
-~----------~----~----~----~------~----~------~--~---
