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 Kiddy wrote: > 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 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?
> 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
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 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
> 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.
On Mar 28, 2:51 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> 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).
> 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.
> On 4/4/07 5:49 PM, bren...@mozilla.org wrote: >> 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.
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.
> > 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.
/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?
bren...@mozilla.org wrote: > 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.
bren...@mozilla.org wrote: > On Apr 4, 4:20 pm, T Rowley <t...@acm.org> wrote: >> On 4/4/07 5:49 PM, bren...@mozilla.org wrote:
>>> 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.
> /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?
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.
bren...@mozilla.org wrote: > On Apr 4, 4:20 pm, T Rowley <t...@acm.org> wrote: >> Fedora Core 6 ships Firefox as a maze of twisty little DSOs; not sure >> about other linux distributions.
> /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?
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).
On Saturday 2007-04-07 01:14 -0400, Andrew Schultz wrote:
> 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
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.
> 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 Mosedale wrote: > 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.
