packaging parts of Mozilla as standalone
Ray Kiddy
It seems to be acknowledged by most people that the Mozilla build system
is complex, arcane and can be off-putting to newcomers.
Perhaps making some of the internal dependencies clearer can be part of
the solution. A concrete way to do this is to create standalone packages
that vend a part of the Mozilla "soup" as libraries.
Many parts of the system could be sliced out and of course this would be
very complicated and probably not worth it right now and so forth and so on.
But to make a start, we could pick one module that is already fairly
well-defined. That module can be used to work out how this could be
built as a stand-alone product, how the builds of different product
would reference this product, how binaries could be distributed and so on.
NSPR is already buildable in a stand-alone manner. If it was to be
built, packaged, and used in a stand-alone manner, what would the
ramifications be?
- ray
Benjamin Smedberg
> NSPR is already buildable in a stand-alone manner. If it was to be
> built, packaged, and used in a stand-alone manner, what would the
> ramifications be?
NSPR is already built and packaged standalone. See
ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases
These builds are performed by the NSPR team, not by mozilla release
engineering, of course.
Are you asking what the ramifications would be if Firefox tried to use these
prepackaged builds, instead of building NSPR itself?
--BDS
Ray Kiddy
Yes.
I know one effect would be that if one had built browser, mail, and
calendar, for example, one could have just one copy of NSPR.
And I see that some of the versions in the page you refer to above even
include objects. I'll have to see if they will build for Mac OS X. I did
not know anyone still used HP-UX. Hm.
So, what would the build system implications be of building against an
externally downloaded object such as this?
- ray
Benjamin Smedberg
> I know one effect would be that if one had built browser, mail, and
> calendar, for example, one could have just one copy of NSPR.
Oh, I don't think we would ever do that (on Windows or Mac, at least) until
we had a shared XULRunner. We still have to ship all of our dependencies
with Firefox, even if they start out as external dependencies. And since we
want to support relocatable and non-sysadmin installs, we don't install
anything to c:\windows\system32 or /Library/Frameworks
> And I see that some of the versions in the page you refer to above even
> include objects. I'll have to see if they will build for Mac OS X. I did
> not know anyone still used HP-UX. Hm.
NSPR and NSS support many many flavors of *nix systems, as well as old
windows nt3.1 and win95 support that has long been dropped from mozilla.
Remember that Mozilla still builds on OS/2!
> So, what would the build system implications be of building against an
> externally downloaded object such as this?
The build system currently support unix-style --with-system-nspr and
--with-system-nss for Linux distributions. That doesn't solve the hard
problem, which is how we actually pull, ship, and tag those pieces with our
Windows/Mac builds.
--BDS
bre...@mozilla.org
> Ray Kiddy wrote:
> > I know one effect would be that if one had built browser, mail, and
> > calendar, for example, one could have just one copy of NSPR.
>
> Oh, I don't think we would ever do that (on Windows or Mac, at least) until
> we had a shared XULRunner. We still have to ship all of our dependencies
> with Firefox, even if they start out as external dependencies. And since we
> want to support relocatable and non-sysadmin installs, we don't install
> anything to c:\windows\system32 or /Library/Frameworks
Right.
Plus, PIC costs and DSOs/DLLs cost too much. We went to a Firefox
static build for a reason. XULRunner can amortize most of the cost
with one big dynamic library, with the right linkage and symbol
hiding, I hope. But the idea that we would ship Firefox as a maze of
twisty little DLLs died in the late '90s, at least elsewhere (Mozilla
may have lived with it as a zombie in the early 00s).
/be
T Rowley
> Plus, PIC costs and DSOs/DLLs cost too much. We went to a Firefox
> static build for a reason. XULRunner can amortize most of the cost
> with one big dynamic library, with the right linkage and symbol
> hiding, I hope. But the idea that we would ship Firefox as a maze of
> twisty little DLLs died in the late '90s, at least elsewhere (Mozilla
> may have lived with it as a zombie in the early 00s).
Fedora Core 6 ships Firefox as a maze of twisty little DSOs; not sure
about other linux distributions.
-tor
Robert Kaiser
And I guess it's quite slow there compared to the version we offer for
download, at least on machines with e.g. slow hard disk performance.
Robert Kaiser
bre...@mozilla.org
/me stifles Linux-abusive knee-jerk reaction
How is the performace (startup, new window, even page load) compared
to Mozilla's static build? Anyone know?
/be
Bart: Dad, you killed the zombie Flanders!
Homer: He was a zombie?
Benjamin Smedberg
> How is the performace (startup, new window, even page load) compared
> to Mozilla's static build? Anyone know?
It's not great. By non-scientific visual comparisons, m.o. builds start up
10-30% faster. Runtime performance differences are not noticable to me at least.
--BDS
Axel Hecht
I'm not sure about the what's in Fedora 6, but caillon and I chatted
about what they have in there, and AFAIK, they have all language packs
in their chrome dir and register those, too. caillon blamed some of
their startup perf problems on that, too.
Axel
Andrew Schultz
I just tested startup (loading about:blank and immediately exit):
CPU time used (seconds):
cold warm
FC6 5.5 0.95
mozilla.org 7.0 0.83
wallclock time (seconds):
FC6 6.4 1.3
mozilla.org 7.6 1.2
Both were firefox 1.5.0.10. A "warm" start was starting the build after
having previously started the same build. A "cold" start was starting
after previously starting the other build.
I started both with run-mozilla.sh instead of the firefox script...
FC6's /usr/bin/firefox seems to not have had much of an update since the
Mozilla suite days. It still has an open_mail() function. Using
/usr/bin/firefox adds about 0.1s to the wallclock time.
So don't spend too much time stifling. It's (to some extent) an apples
to oranges comparison. In addition to the use of more shared libs, the
FC6 build has pango and xinerama enabled and was built with gcc 4.1.1
(as opposed to 3.2.2 for .mozilla.org's).
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
L. David Baron
> So don't spend too much time stifling. It's (to some extent) an apples
> to oranges comparison. In addition to the use of more shared libs, the
> FC6 build has pango and xinerama enabled and was built with gcc 4.1.1
> (as opposed to 3.2.2 for .mozilla.org's).
Were the shared libraries prelinked? That can also improve startup
performance (as can the newer compiler).
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Andrew Schultz
> I just tested startup (loading about:blank and immediately exit):
>
> CPU time used (seconds):
> cold warm
> FC6 5.5 0.95
> mozilla.org 7.0 0.83
>
> wallclock time (seconds):
> FC6 6.4 1.3
> mozilla.org 7.6 1.2
In the interest of providing more meaningful data, I compiled a static
firefox myself with FC6's options (pango, xinerama) using gcc 4.1.1.
cold warm
CPU itme 7.2 0.85
wallclock time 8.1 1.2
So, a cold start is slower than with FC6 or official .mozilla.org builds
and a warm start is about the same as official builds.
I also ran Txul. FC6's build's time was 300ms and my static build was
290ms.
The FC6 binaries and libs are prelinked. I tried prelinking the
.mozilal.org build and my own static build, but the impact on the perf
was below the noise level.
Dan Mosedale
>
> Both were firefox 1.5.0.10. A "warm" start was starting the build after
> having previously started the same build. A "cold" start was starting
> after previously starting the other build.
I'm not sure this methodology really tests a "cold" start. In
particular, unless you have so little memory that starting one different
copy of Firefox forces the previous copy to be evicted from the cache,
you may well have most of the same copy of Firefox still in memory. I
suspect that to get really good numbers, you'd need to reboot before
each cold start.
Dan
Andrew Schultz
> I'm not sure this methodology really tests a "cold" start. In
> particular, unless you have so little memory that starting one different
> copy of Firefox forces the previous copy to be evicted from the cache,
> you may well have most of the same copy of Firefox still in memory. I
> suspect that to get really good numbers, you'd need to reboot before
> each cold start.
Sure. The "coldness" isn't really related to cache but to component and
chrome re-registration.