[chromium-dev] Re: Making sense of startup
Neither of these examples is particularly complex or requiring a makefile rule solver to resolve. Both Evan and Nick's examples are one component depending on one other component. I would call that a "simple" dependency that is easy to document in a comment and to maintain correctly when editing the code. Neither of these examples required modifying any other parts of startup, much less "complex reorganization," to satisfy their requirements. Brett On Thu, Jan 15, 2009 at 4:10 PM, Evan Martin wrote: > > On Thu, Jan 15, 2009 at 3:06 PM, Brett Wilson wrote: >> >> On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay wrote: >>> The issue is one of maintenance. A lot happens at startup. As people >>> make changes, it's not necessarily obvious where to insert your >>> initialization code. Depending on your dependencies, your new service >>> may require a complex re-ordering of initialization. If we actually >>> explicitly express dependencies and automatically manage them, then we >>> can be precise about it. >> >> I'm still a bit skeptical of how complex these dependencies are. Can >> somebody give an example of such a service that required complex >> interdependencies on startup and required very specific ordering? > > Another one > http://src.chromium.org/viewvc/chrome?view=rev&revision=5069 > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
On Thu, Jan 15, 2009 at 3:06 PM, Brett Wilson wrote: > > On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay wrote: >> The issue is one of maintenance. A lot happens at startup. As people >> make changes, it's not necessarily obvious where to insert your >> initialization code. Depending on your dependencies, your new service >> may require a complex re-ordering of initialization. If we actually >> explicitly express dependencies and automatically manage them, then we >> can be precise about it. > > I'm still a bit skeptical of how complex these dependencies are. Can > somebody give an example of such a service that required complex > interdependencies on startup and required very specific ordering? Another one http://src.chromium.org/viewvc/chrome?view=rev&revision=5069 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
On Thu, Jan 15, 2009 at 3:06 PM, Brett Wilson wrote: > > On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay wrote: > > The issue is one of maintenance. A lot happens at startup. As people > > make changes, it's not necessarily obvious where to insert your > > initialization code. Depending on your dependencies, your new service > > may require a complex re-ordering of initialization. If we actually > > explicitly express dependencies and automatically manage them, then we > > can be precise about it. > > I'm still a bit skeptical of how complex these dependencies are. Can > somebody give an example of such a service that required complex > interdependencies on startup and required very specific ordering? see browser_main.cc at line 164 : -=-=-=-=-=-= // Start tracking the creation and deletion of Task instance. // This construction MUST be done before main_message_loop, so that it is // destroyed after the main_message_loop. tracked_objects::AutoTracking tracking_objects; MessageLoop main_message_loop(MessageLoop::TYPE_UI); -=-=-=-=-=-= If we move main_message_loop above tracking_objects, when the function ends and all the local objects are deleted, tracking objects will be deleted first and that will caused a crash in the destructor of MessageLoop. Nicolas > > > Brett > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay wrote: > The issue is one of maintenance. A lot happens at startup. As people > make changes, it's not necessarily obvious where to insert your > initialization code. Depending on your dependencies, your new service > may require a complex re-ordering of initialization. If we actually > explicitly express dependencies and automatically manage them, then we > can be precise about it. I'm still a bit skeptical of how complex these dependencies are. Can somebody give an example of such a service that required complex interdependencies on startup and required very specific ordering? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
Separate phase functions sounds good to me. We should make it clear that
stuff within a phase should not be interdependent, but that might be hard to
verify and enforce :-/
-Darin
On Thu, Jan 15, 2009 at 2:18 PM, Ben Goodger (Google) wrote:
>
> Here's my plan. The Mac and Linux people are probably going to proceed
> just by using ifdefs to get the startup sequence up and running, but
> in the process learn more about what goes on where. We can first split
> into separate phase functions for readability, and then after that
> figure out if any further steps are needed.
>
> -Ben
>
> On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay wrote:
> >
> > On Thu, Jan 15, 2009 at 1:37 PM, Brett Wilson
> wrote:
> >>
> >> On Thu, Jan 15, 2009 at 1:19 PM, Amanda Walker
> wrote:
> >>>
> >>> That's true. In the example I gave (Mac driver loading), each module
> >>> has a property list that lists its dependencies (and version
> >>> requirements, etc.). That's not quite as simple to do inside a single
> >>> application, of course, but having code do the ordering still seems
> >>> like a win to me.
> >>>
> >>> Consider startup as a sequence of, say:
> >>>
> >>> Initializer foo("foo");
> >>> foo.DependsOn("bar");
> >>> foo.DependsOn("zot");
> >>>
> >>> Initializer alice("alice");
> >>> alice.DependsOn("bob");
> >>> alice.DependsOn("eve");
> >>> [...]
> >>> Initializer::LaunchAll();
> >>>
> >>> (or, more generally, "Initializer:::Launch("chromium");" where
> >>> "chromium" is a top level module, so that the general framework could
> >>> be used for things besides app launch)
> >>
> >> I have a hard time thinking about this with your abstract example. I
> >> also have a hard time believing we have so many interdependencies that
> >> it requires writing a makefile to start the program, and that such a
> >> syntax is easier to read than just listing out in comments why things
> >> are done in this order.
> >
> > The issue is one of maintenance. A lot happens at startup. As people
> > make changes, it's not necessarily obvious where to insert your
> > initialization code. Depending on your dependencies, your new service
> > may require a complex re-ordering of initialization. If we actually
> > explicitly express dependencies and automatically manage them, then we
> > can be precise about it.
> >
> > Maybe we'd have to see an example to know for sure, but it feels like
> > it would be easier to read startup dependencies if they were expressed
> > explicitly as opposed to comments which don't need to be complete and
> > can drift from reality.
> >
> > Erik
> >
> > >
> >
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
Here's my plan. The Mac and Linux people are probably going to proceed
just by using ifdefs to get the startup sequence up and running, but
in the process learn more about what goes on where. We can first split
into separate phase functions for readability, and then after that
figure out if any further steps are needed.
-Ben
On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay wrote:
>
> On Thu, Jan 15, 2009 at 1:37 PM, Brett Wilson wrote:
>>
>> On Thu, Jan 15, 2009 at 1:19 PM, Amanda Walker wrote:
>>>
>>> That's true. In the example I gave (Mac driver loading), each module
>>> has a property list that lists its dependencies (and version
>>> requirements, etc.). That's not quite as simple to do inside a single
>>> application, of course, but having code do the ordering still seems
>>> like a win to me.
>>>
>>> Consider startup as a sequence of, say:
>>>
>>> Initializer foo("foo");
>>> foo.DependsOn("bar");
>>> foo.DependsOn("zot");
>>>
>>> Initializer alice("alice");
>>> alice.DependsOn("bob");
>>> alice.DependsOn("eve");
>>> [...]
>>> Initializer::LaunchAll();
>>>
>>> (or, more generally, "Initializer:::Launch("chromium");" where
>>> "chromium" is a top level module, so that the general framework could
>>> be used for things besides app launch)
>>
>> I have a hard time thinking about this with your abstract example. I
>> also have a hard time believing we have so many interdependencies that
>> it requires writing a makefile to start the program, and that such a
>> syntax is easier to read than just listing out in comments why things
>> are done in this order.
>
> The issue is one of maintenance. A lot happens at startup. As people
> make changes, it's not necessarily obvious where to insert your
> initialization code. Depending on your dependencies, your new service
> may require a complex re-ordering of initialization. If we actually
> explicitly express dependencies and automatically manage them, then we
> can be precise about it.
>
> Maybe we'd have to see an example to know for sure, but it feels like
> it would be easier to read startup dependencies if they were expressed
> explicitly as opposed to comments which don't need to be complete and
> can drift from reality.
>
> Erik
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
On Thu, Jan 15, 2009 at 1:37 PM, Brett Wilson wrote:
>
> On Thu, Jan 15, 2009 at 1:19 PM, Amanda Walker wrote:
>>
>> That's true. In the example I gave (Mac driver loading), each module
>> has a property list that lists its dependencies (and version
>> requirements, etc.). That's not quite as simple to do inside a single
>> application, of course, but having code do the ordering still seems
>> like a win to me.
>>
>> Consider startup as a sequence of, say:
>>
>> Initializer foo("foo");
>> foo.DependsOn("bar");
>> foo.DependsOn("zot");
>>
>> Initializer alice("alice");
>> alice.DependsOn("bob");
>> alice.DependsOn("eve");
>> [...]
>> Initializer::LaunchAll();
>>
>> (or, more generally, "Initializer:::Launch("chromium");" where
>> "chromium" is a top level module, so that the general framework could
>> be used for things besides app launch)
>
> I have a hard time thinking about this with your abstract example. I
> also have a hard time believing we have so many interdependencies that
> it requires writing a makefile to start the program, and that such a
> syntax is easier to read than just listing out in comments why things
> are done in this order.
The issue is one of maintenance. A lot happens at startup. As people
make changes, it's not necessarily obvious where to insert your
initialization code. Depending on your dependencies, your new service
may require a complex re-ordering of initialization. If we actually
explicitly express dependencies and automatically manage them, then we
can be precise about it.
Maybe we'd have to see an example to know for sure, but it feels like
it would be easier to read startup dependencies if they were expressed
explicitly as opposed to comments which don't need to be complete and
can drift from reality.
Erik
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
I don't know how many interdependencies we have--I was relying on
ben's "everyone and their dog" assessment :-). That said, I write a
makefile (or equivalent) for anything with >2 source files, so writing
the dependencies in code rather than comments doesn't strike me as a
large cost.
--Amanda
On Thu, Jan 15, 2009 at 4:37 PM, Brett Wilson wrote:
>
> On Thu, Jan 15, 2009 at 1:19 PM, Amanda Walker wrote:
>>
>> That's true. In the example I gave (Mac driver loading), each module
>> has a property list that lists its dependencies (and version
>> requirements, etc.). That's not quite as simple to do inside a single
>> application, of course, but having code do the ordering still seems
>> like a win to me.
>>
>> Consider startup as a sequence of, say:
>>
>> Initializer foo("foo");
>> foo.DependsOn("bar");
>> foo.DependsOn("zot");
>>
>> Initializer alice("alice");
>> alice.DependsOn("bob");
>> alice.DependsOn("eve");
>> [...]
>> Initializer::LaunchAll();
>>
>> (or, more generally, "Initializer:::Launch("chromium");" where
>> "chromium" is a top level module, so that the general framework could
>> be used for things besides app launch)
>
> I have a hard time thinking about this with your abstract example. I
> also have a hard time believing we have so many interdependencies that
> it requires writing a makefile to start the program, and that such a
> syntax is easier to read than just listing out in comments why things
> are done in this order.
>
> Brett
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
On Thu, Jan 15, 2009 at 1:19 PM, Amanda Walker wrote:
>
> That's true. In the example I gave (Mac driver loading), each module
> has a property list that lists its dependencies (and version
> requirements, etc.). That's not quite as simple to do inside a single
> application, of course, but having code do the ordering still seems
> like a win to me.
>
> Consider startup as a sequence of, say:
>
> Initializer foo("foo");
> foo.DependsOn("bar");
> foo.DependsOn("zot");
>
> Initializer alice("alice");
> alice.DependsOn("bob");
> alice.DependsOn("eve");
> [...]
> Initializer::LaunchAll();
>
> (or, more generally, "Initializer:::Launch("chromium");" where
> "chromium" is a top level module, so that the general framework could
> be used for things besides app launch)
I have a hard time thinking about this with your abstract example. I
also have a hard time believing we have so many interdependencies that
it requires writing a makefile to start the program, and that such a
syntax is easier to read than just listing out in comments why things
are done in this order.
Brett
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
That's true. In the example I gave (Mac driver loading), each module
has a property list that lists its dependencies (and version
requirements, etc.). That's not quite as simple to do inside a single
application, of course, but having code do the ordering still seems
like a win to me.
Consider startup as a sequence of, say:
Initializer foo("foo");
foo.DependsOn("bar");
foo.DependsOn("zot");
Initializer alice("alice");
alice.DependsOn("bob");
alice.DependsOn("eve");
[...]
Initializer::LaunchAll();
(or, more generally, "Initializer:::Launch("chromium");" where
"chromium" is a top level module, so that the general framework could
be used for things besides app launch)
Just some ideas,
--Amanda
On Thu, Jan 15, 2009 at 4:04 PM, Erik Kay wrote:
>
> On Thu, Jan 15, 2009 at 11:11 AM, Ben Goodger (Google)
> wrote:
>> I'm not coming at this from an optimization perspective, I'm thinking
>> more of making the startup flow understandable to mere mortals.
>
> Amanda's suggestion would likely actually accomplish both, so I don't
> think we should dismiss it if it happens to make startup faster as a
> result as well. :-)
>
> The gist would be to have some way for a given service to specify its
> startup dependencies. Once you do that, then you can essentially list
> your startup services in pretty much any order since the dependencies
> would get worked out correctly. It would also allow us to catch
> things like dependency cycles and to more clearly figure out how to
> optimize startup time by perhaps figuring out how to remove
> unnecessary dependencies. Finally, it would allow easier unit testing
> since you'd be able to safely grab a subset of the services you want
> to test and to have a system that knows how to initialize properly
> (addressing Scott's issue).
>
> Of course, coming up with a nice way to express these dependencies
> cleanly and actually figuring out what all of the dependencies are are
> both easier said than done.
>
> Erik
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
On Thu, Jan 15, 2009 at 11:11 AM, Ben Goodger (Google) wrote: > I'm not coming at this from an optimization perspective, I'm thinking > more of making the startup flow understandable to mere mortals. Amanda's suggestion would likely actually accomplish both, so I don't think we should dismiss it if it happens to make startup faster as a result as well. :-) The gist would be to have some way for a given service to specify its startup dependencies. Once you do that, then you can essentially list your startup services in pretty much any order since the dependencies would get worked out correctly. It would also allow us to catch things like dependency cycles and to more clearly figure out how to optimize startup time by perhaps figuring out how to remove unnecessary dependencies. Finally, it would allow easier unit testing since you'd be able to safely grab a subset of the services you want to test and to have a system that knows how to initialize properly (addressing Scott's issue). Of course, coming up with a nice way to express these dependencies cleanly and actually figuring out what all of the dependencies are are both easier said than done. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 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)
> 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
On Thu, Jan 15, 2009 at 11:55 AM, Jim Roskind 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. Agreed--but often (a) is used as a proxy for an ordering constraint on code that's actually (b). Documenting ordering constraints is good; implementing them in code would be even better (assert/DCHECK would be a good start, but code that actually does the ordering would be even better). Apple did a great job of this a few revs back of Mac OS X when they made most of the OS boot in parallel--each module and driver is tagged with what it depends on rather than insisting on being in a single place in a single-threaded "startup" routine or script, and the startup code orders them at runtime. It seems like we could do something similar for application startup--a middle ground between "initialize everything sequentially in a single thread" and "initialize everything lazily". --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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) 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
Another problem with moving everything out of browserinit is unit tests. It's much easier for unit tests to call a single function to startup and one for shutdown instead of having to call out to a bunch of services to explicitly shut them down. -Scott On Wed, Jan 14, 2009 at 11:34 PM, Darin Fisher wrote: > the winsock initialization can be removed now that we have EnsureWinSockInit > which should be called by any code that uses winsock. (we may not have > sprinkled that in all of the right places, but you get the idea.) > i really like your idea of documenting startup dependencies, and i agree > that the reason for a lot of this is to deal with required orderings. if we > were to try to make everything lazily init via Singleton or function > statics, we'd then potentially have shutdown ordering problems as we also > have to be careful about the order in which things get torn down. sometimes > it is just better to lay things out carefully at startup and shutdown > instead of trying to do everything in a cleverly lazy fashion. of course > that doesn't work if startup (and shutdown) are treated like dumping grounds > as has been the case :-( > > -darin > > On Wed, Jan 14, 2009 at 3:08 AM, Dean McNamee wrote: >> >> +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 >> wrote: >> > On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) >> > >> > 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
the winsock initialization can be removed now that we have EnsureWinSockInit which should be called by any code that uses winsock. (we may not have sprinkled that in all of the right places, but you get the idea.) i really like your idea of documenting startup dependencies, and i agree that the reason for a lot of this is to deal with required orderings. if we were to try to make everything lazily init via Singleton or function statics, we'd then potentially have shutdown ordering problems as we also have to be careful about the order in which things get torn down. sometimes it is just better to lay things out carefully at startup and shutdown instead of trying to do everything in a cleverly lazy fashion. of course that doesn't work if startup (and shutdown) are treated like dumping grounds as has been the case :-( -darin On Wed, Jan 14, 2009 at 3:08 AM, Dean McNamee wrote: > > +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 > wrote: > > On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) > > > 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
+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 wrote: > On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) > 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
