This is very cool work, it'll especially be useful for outside developers
who don't have our beefy machines :)
Would it be possible to get a sense of what percentage of chrome.dll is due
to our code (i.e. base, net, chrome) vs third party (i.e. everything in
\third_party including webkit)? Perhaps this estimate can be calculated by
looking at obj file size. My hunch is that if we were to move off
everything in third_party, that would get rid of a huge amount of code that
hardly changes and it would be easier because that code is self contained
(i.e. none of the problems that you mention below).
On Tue, Aug 25, 2009 at 3:25 PM, Nicolas Sylvain <nsylv...@chromium.org>wrote:
> Hello,
> In the past a lot of you have asked to split up chrome.dll in multiple
> DLLs. For this quarter, I had a goal to see how feasible this is.
>
> Background information:
>
> Breaking up chrome.dll would make linking time faster and use less memory.
> It would also enforce a cleaner cut between our modules. Eventually
> it might make some of the modules be more easily reusable or swappable.
>
> This is likely not suitable for release or official builds, because adding
> more dlls means slower startup time. And the penalty we would get from
> loading 2 or 3 more dlls won't be acceptable.
>
> This is why the scope of this change is Debug mode only. (Actually, it
> would be possible to enable this with a gyp define for release too, but it
> would
> be enabled by default only in debug). Oh, and this is Windows only for now
> too. (Linux already supports that AFAIK)
>
> The results:
>
> The good news is that it is feasible. The bad news is that the cost
> associated with it might be too high.
> This is what we need to decide here.
>
> I started by looking at base and net. Right now I have a checkout that can
> build the full solution with a base.dll and a net.dll. (205 modified files)
>
> The initial goal was to export only what was needed, but since the unit
> tests do a good job at testing almost everything, then
> we were exporting almost everything, so I am now exporting full classes
> instead. This is a lot less intrusive
> and the code is cleaner, even though the export table can look a little bit
> ugly.
>
> Some of the problems I am seeing:
>
> - ICU needs to be registered per module. Right now since the Initialize
> function is in base.dll, it always get initialized there, even though it's
> called
> by other dlls. We would need to move to a more central dll icu mode. I
> think it's already supported.
>
> - Some classes in base were clearly designed to be in a lib. One example is
> PathService. Right now when I call PathService::Get(FILE_MODULE), I
> always get "base.dll". There are some similar problems with the VersionInfo
> classes. The solution here would be to create a new project called
> base_lib, which is always a lib. Unfortunately, PathService depends on a
> lot of other base classes, so base.lib would need to depend on base.dll, and
> base.dll would need to depend on base.lib (since it does use PathService).
> So a major cleanup would be required here. I'm sure we can find a better
> solution though.
>
> - Global variables are not global for the app, they are global per module.
> So if you use a lib that has a global variables, and this is used
> from multiple dlls (base, net, chrome, etc), then they will have different
> values. The solution here would be to move this lib to a dll too.
>
> - Singleton. They are not too much of an issue right now because they seem
> to be all registered by base.dll, but there is a risk that you would
> have multiple instances of a singleton. (one per module).
>
> Eventually we would like to be able to split webkit in it's own dll too. I
> heard to it's not possible right now due to some inter-dependency problems,
> but people are working on that. Webkit was designed to be in its own dll,
> so it should be less of a problem.
>
> My next step is to back off a little bit from base and net, and go look at
> the other more self contained modules, like libxml and the rest of the
> third_party libs we use.
>
> Depending on the feedback on this thread, I will trash the base/net split,
> or finish it.
>
> Let me know what you think. I want to know if you have huge concerns about
> this, or if you think this would result in too much code
> change for benefit we would get out of it.
>
> Thanks
>
> Nicolas
>
> [Oh, and right now i'm using the DLL CRT, not tcmalloc. This is something
> else I will need to get working before we can roll this out]
>
>
>
>
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
