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