Closed Bug 271770 Opened 20 years ago Closed 20 years ago

extension format on disk needs compressing to 1 file

Categories

(Toolkit :: Add-ons Manager, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mozilla, Assigned: bugs)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 

When I first got firefox I was all excited by the extensions and loaded a 
bunch that made my life easier and were just generally cool -- however, I 
began to notice that loading firefox (even after disk defrags and boot defrags 
where firefox was one of the initial apps loaded during the bootup phase) that 
firefox took at least 2-4x to load as MS Internet Exploder.  Yuck.  I wiped 
all the extensions and it still often loads more slowly than IE as well as 
using more CPU and more memory.  But I was thinking about the extension 
problem in particular -- instead of storing them all in separate files -- 
maybe after adding an extension it could be optimized by putting the extension 
in 1 larger extension file (that hopefullly would be defragged by those that
defrag regularly).  At least it would only require 1 file open and maybe 1 
contiguous read.  The individual components could still be stored on disk, but 
the metafile containing all extensions could be rebuilt whenever an extension 
is modified/updated/added or deleted.  Just an 'on disk' optimization to lower 
I/O overhead that might reduce the time before FF is ready for user input.

Reproducible: Always
Steps to Reproduce:
1. add 20 or so extensions...watch load time increase accordingly
2.
3.

Actual Results:  
slow file seeks, opens and reads of small files likely spread out over disk.

Expected Results:  
Read 1 file, with one large read of a defrag'ed extension-summary file.


Marking this as critical, since the long load time associated with using a 
large number of extensions makes FF impractical to use on a stop/start basis 
while the large memory footprint makes it undesirable to keep in memory all 
the time.

I'm running on a laptop with a 7200RPM(60Mb) drive, 1G Mobile-PIII processor 
with memory maxed out at 512Mb.  I defrag the drive twice daily for both boot
optimization and regular optimization and average 0% fragmentation (disk about
66% full); pagefile (rarely used) and other system files defragged regularly
as well using sysinternals.com pagedfrg util (free).

FF's large memory and CPU usage could be the one major stumbling block keeping 
it from being a major IE killer.  Reliance, totally on home-rolled libraries 
for all functions, while great for portability, sucks for shared memory usage 
and general, native OS integration.  It would be GREAT if there was a way to 
use native libraries for similar functions when available...but don't know how 
viable this idea would be.
There *is* such a file already, as far as I understand. The XUL cache file
(xul.mfl or something similar in your profile). It stores precompliled chrome
read from jars. I think that Mozilla reads jar files, though.

So my bet is: this is either invalid or wontfix.
(btw, have you got any real numbers?)
Severity: major → enhancement
invalid, per comment 1.

you may search bugzilla for bugs open on this issue, there are a few.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.