MozillaZine

Full Article Attached New Mozilla Cache Lands!

Tuesday March 20th, 2001

The new cache, which will be used for HTTP, FTP, and the new imagelib (which uses part of the memcache for decompressed images) landed today. With this ground-up rewrite the loading of cached copies should be "significantly faster." Check out the full story for an excellent summary of this new cache from Gagan Saksena and to find out how you can help test the new cache.

UPDATE - there is a problem with the old cache that conflicts with the new cache. Before you run a build with the new cache, you should manually delete the contents of your cache directories. If you go back to an old build, you should perform the same duty again. For more information and to track the status of this see the bug.

#1 XUL?

by ERICmurphy

Tuesday March 20th, 2001 6:23 PM

What about the XUL Cache? Or is that separate?

#2 $100 mil

by rgelb

Tuesday March 20th, 2001 6:34 PM

The 100 million question is: will it make Moz start faster?

#25 Re: $100 mil

by bugs4hj

Friday March 23rd, 2001 12:46 AM

no it won't

#33 Yes, it will

by damian

Friday March 23rd, 2001 1:19 PM

According to the developers in the latest status report http://www.mozilla.org/status/2001-03-21.html , yes, it will.

"Initial browser load time results with the new cache look great!"

#38 But ...

by gerbilpower

Friday March 23rd, 2001 1:52 PM

But that could mean that the load times of pages look great, not the load time to start the browser. The comment in the status report is quite vague.

Alex

#35 Yes, it will

by damian

Friday March 23rd, 2001 1:20 PM

According to the developers in the latest status report http://www.mozilla.org/status/2001-03-21.html , yes, it will.

"Initial browser load time results with the new cache look great!"

#36 Sorry. double posting (n/t)

by damian

Friday March 23rd, 2001 1:24 PM

n/t

#37 Sorry. double posting (n/t)

by damian

Friday March 23rd, 2001 1:24 PM

n/t

#3 may be we have to ...

by billi_kid

Tuesday March 20th, 2001 7:22 PM

make some fondation with idial target to sponsor mozila to start faster.... ..if anyone of use sends $1 to mozilla it will be enough as sign that we want mozilla to start faster:)))

just kidding .... but it's sad

#4 may be we have to ...

by billi_kid

Tuesday March 20th, 2001 7:23 PM

i meant anyone of us sorry

#26 Re: may be we have to ...

by bugs4hj

Friday March 23rd, 2001 12:51 AM

You might try a faster computer or just show me the money and i will send you something showing the first screen just under 5 secs, on any average computersystem!

#27 that's such a response from a coder.

by sgedikian

Friday March 23rd, 2001 2:20 AM

let's be realistic, moz does start pretty fast, faster is always better... but it won't be as fast as ie "starts" up, ever.

-s

#28 Re: that's such a response from a coder.

by bugs4hj

Friday March 23rd, 2001 4:45 AM

The mozilla team is working hard to reduce the footprint and to make mozilla start a bit faster. Buzzword here is 'precompiled' code. Precompiled source means no comments, no whitespaces and reformatted text.

I just took a javascript file and crunched it from 32964 to 16948 bytes. So if we take all javascript files from the jar files, and crunch it like that, then you would see the difference!

Smaller files, less memory consumption and a faster startup for mozilla. Just to be more realistic :)

#29 Re: Re: that's such a response from a coder.

by strauss

Friday March 23rd, 2001 4:59 AM

How about preparsing them to a binary DOM representation, conceptually similar to Enhydra? The HTML -> DOM step must be eating up a big chunk of that time.

#30 Re: Re: Re: that's such a response from a coder.

by dave532

Friday March 23rd, 2001 8:45 AM

Dunno about the viability of that, but please discuss it on the newsgroups if it has not been discussed before and file a RFE in bugzilla if people think it's a good idea.

#34 code cruncher

by fitz

Friday March 23rd, 2001 1:19 PM

http://www.brainjar.com/js/crunch/

#44 Re: code cruncher

by klee

Friday March 23rd, 2001 4:20 PM

Filed a bug for this: http://bugzilla.mozilla.org/show_bug.cgi?id=73256

#31 Re: that's such a response from a coder.

by FrodoB

Friday March 23rd, 2001 8:53 AM

Whoa, cool.... Didn't know that Nullsoft's most wormy guy was interested in Mozilla. :)

#40 not true

by joschi

Friday March 23rd, 2001 2:57 PM

there is a bug report on a project to have parts of mozilla preloaded on OS start like IE does, and hence Moz will start as fast or faster. This will be totally optional and configurable of course. Never say never.

#45 Re: not true

by Martyr

Friday March 23rd, 2001 4:54 PM

Agreed! The biggest problem with any change, no matter how small, no matter how good that change is, is apathetic, lazy defeatists who can't even bother to concieve victory!

#41 not true

by joschi

Friday March 23rd, 2001 2:58 PM

there is a bug report on a project to have parts of mozilla preloaded on OS start like IE does, and hence Moz will start as fast or faster. This will be totally optional and configurable of course. Never say never.

#42 grrr....

by joschi

Friday March 23rd, 2001 2:59 PM

that was supposed to be a reply to "that's such a response from a coder."

#46 Re: that's such a response from a coder.

by mattdm

Friday March 23rd, 2001 9:12 PM

It *could* "start up" as fast as IE....

http://bugzilla.mozilla.org/show_bug.cgi?id=36283

#48 Re: Re: may be we have to ...

by thelem

Saturday March 24th, 2001 5:06 PM

And if you have a fast computer (Athlon 800) which you spent all your money on?

#5 Will this be in .81?

by Waldo

Tuesday March 20th, 2001 7:34 PM

This, and the changes described in today's Asa report will be in the .81 build right? (or .8.1 or whatever it's gonna be called...)

W

#7 no

by asa

Tuesday March 20th, 2001 8:17 PM

this will not be in 0.8.1. changes of this magnitude are landed at the beginning of a development cycle, not the end (the mail news perf branch will not be in 0.8.1 either)

--Asa

#8 Re: no

by Waldo

Tuesday March 20th, 2001 8:21 PM

Awww bummer. Back in the day I was grabbing nightly builds but in the last few months I've only gotten the big ones.. Guess I'll be back to nightlies again ;)

W

#16 It's well worth it

by beastie

Wednesday March 21st, 2001 10:46 AM

I enjoy getting the new features every day as they creep out.

#18 Yeah, but..

by Waldo

Wednesday March 21st, 2001 10:58 AM

It kinda sucks to have to re-set everything up-- plugins, bookmarks, yadda yadda..esp. if there's something f-d up about the build, although I suppose that's where asa helps out ;)

W

#22 Re: Yeah, but..

by beastie

Wednesday March 21st, 2001 1:27 PM

I use the same profile until I run into a problem, then I toast it. So I don't actually rebuild my bookmarks that often. And when I do, they're just imported from my 4.x profile.

#32 re-import bookmarks?

by NikoP

Friday March 23rd, 2001 9:15 AM

I backup my bookmarks.html-file every 3 or 4 weeks and if I'm getting trouble with the current moz-profile I first try the old bookmark file in the new profile and only if I'm still having problems with the bookmarks I re-import my backup file. You don't need to import the 4.x profile again and again

#6 Is Mozilla cache redundant if using SQUID?

by flacco

Tuesday March 20th, 2001 7:57 PM

I us SQUID cache on a separate machine that I use as proxy for my Linux workstation and for my wife's Win box.

Is the Mozilla cache redundant in this case, adding a performance hit?

If so, is it possible to disable Mozilla's cache?

#9 Re: Is Mozilla cache redundant if using SQUID?

by jwb

Tuesday March 20th, 2001 9:31 PM

When using squid, many people turn off the local disk cache in Mozilla but most people leave the memory cache on.

What I'd like to know is if this cache rewrite is going to fix the many, many, numerous problems, crash and otherwise, with the old cache, or if it simply regresses all of the ones that already were fixed.

#10 yeah

by asa

Tuesday March 20th, 2001 11:08 PM

"What I'd like to know is if this cache rewrite is going to fix the many, many, numerous problems, crash and otherwise, with the old cache, or if it simply regresses all of the ones that already were fixed."

yeah. that's what we're all working hard doing. we love to avoid fixing bugs in favor of regressing bugs that are already fixed. if there was a way to mark a question here as invalid I would sure mark this one.

#19 You know you QA too much when...

by hubick

Wednesday March 21st, 2001 11:38 AM

"if there was a way to mark a question here as invalid I would sure mark this one"

You know you have been using Bugzilla too long when...you start trying to deal with Real Life the same way you would a bug report :-)

Girlfriend whining to you...

- Your X GF keeps calling? CLOSED! - Seeing other women (blocker)? UNCONFIRMED! - Don't cuddle enough (trivial)? INVALID! - You never cry (enhancement)? WONTFIX! - Forgeting her birthday? Bought a PDA! FIXED! - Leaving the toilet seat up? REMIND! - Spend too much time surfing for Porn? VERIFIED! - Take out the trash? LATER! - You don't want to fight, let's just forget about it? REOPENED! - She doesn't climax in bed (all platforms)? WORKSFORME!

:-)

#23 lol (n/t)

by aegis

Wednesday March 21st, 2001 2:16 PM

n/t

#11 A little of chide

by jmarranz

Wednesday March 21st, 2001 2:20 AM

Im a follower of the Mozilla Project two years ago.

I think is a little awesome to see modules rewritten from-the-scratch two years ago after (cache and imagelib).

Bad design? Remember Navigator 4.x and browser war ...

We can't make the same mistakes of the past.

#12 Re: A little of chide

by Beafsteak

Wednesday March 21st, 2001 8:01 AM

I think the Imagelib was still mainly from NS4.x and although the cache was rewritten, at least the disk cache, which was AFAIK initially designed by Intel, suffered from neglect by them and was completed relatively late in the dev cycle (I think about a year ago).

#24 Rewrites are a *good* sign...

by ralphmellor

Wednesday March 21st, 2001 6:49 PM

...when it turns out that it doesn't require changes to the component's logical interface. Aiui, this is the case with this new component -- they did not have to (significantly) change the logical interface.

A big reason why open source works so well for large complex projects is that it tends to result in relatively clean design of the logical interfaces between components that go into a system. The *implementation* of individual components themselves can be a horrible hack, but it doesn't matter, because someone can come back and rewrite this parts that don't work without breaking the entire system.

#13 Will this fix View Source?

by sab39

Wednesday March 21st, 2001 8:35 AM

View source (at least in 0.8 and previous) is horribly broken. It doesn't give accurate source (when a page returns nothing at all you still get <html><body></body></html>) and it never seems to actually *use* the cache at all - it does a reload which for many dynamic pages will often get wrong information. And if the original request was a form post, it does a GET instead which means you are guaranteed to get something entirely different.

If the cache landing won't fix this, does anyone know the bug number where I can track the View Source rewrite?

#14 Re: Will this fix View Source?

by jck2000

Wednesday March 21st, 2001 10:34 AM

Check out bugs 55583, 60426 and 64100 on bugzilla. The View Source issues have been bothering me for a while too. There are a number of good improvement extensions, such as allowing helper apps to be designated for viewing/editing and allowing options for viewing of original source prior to client-side processing.

#15 Re: Re: Will this fix View Source?

by jck2000

Wednesday March 21st, 2001 10:35 AM

I meant \"improvement suggestions\" (in the bugzilla database), not \"improvement extensions\". Sorry for waste of bandwidth.

#20 Re: Will this fix View Source?

by gwalla

Wednesday March 21st, 2001 12:10 PM

The reload-when-viewing-source problem is one of the main reasons for the new cache.

#21 Re: Will this fix View Source?

by sleepy

Wednesday March 21st, 2001 1:15 PM

I tried the new cache on jobtrak.com, where you can POST data to search for job listings. I tried to view-source on the POSTed web page, and to my surprise, Mozilla didn't refetch the data from the network! I'm pretty sure about that because I was watching my ethernet traffic light and it didn't go on.

Unfortunately, I couldn't do more testing with the new cache, because the experiemental builds seem 10x as crashy as the nightly builds. Can't wait till the new cache gets into a stable trunk build.

#17 Broken link

by cyfaone

Wednesday March 21st, 2001 10:51 AM

The new cache build link is broken on the hompage

#39 What happened to the build dirs on the buildbar?

by theuiguy

Friday March 23rd, 2001 2:45 PM

It used to say "Today's build directories: linux, mac, and win32" with each day's report on the build comments page. They seem to no longer be there. Can we get them back, please? I found them quite useful.

#43 Re: What happened to the build dirs on the buildba

by gerbilpower

Friday March 23rd, 2001 3:30 PM

I found them useful also. Maybe Asa forgot them since, afterall, they're at a busy period trying to get Mozilla 0.8.1 out.

Alex <:3)~~

#47 Memory usage?

by dannunn

Friday March 23rd, 2001 9:31 PM

Well, I think I finally got a Mozilla win32 build with the cache turned on. How can I tell? Well, the fact that my build from about a week ago used around 29 megs of ram (Windows 2000), and now build 2001-03-23-04 uses 59 (fifty-nine) (!!) megabytes of ram.

Anyway, that aside, about:cache displays all the files in my memory cache now. I think. Well, when I click on them, I get the scrupulous error message, "The cache entry you selected is no longer unavailable." Hmm, if it's no longer unavailable, perhaps you could _SHOW ME_? Or is this a typo? ;)

#49 For haven sak(s)e(na)

by bugs4hj

Sunday March 25th, 2001 12:56 AM

For haven sak(s)e(na), lets all start using this new cache and file bugs against it. Download the latest build and start using it right away.

Remember, Gagan Saksena did an h*ll of a scary job in rewriting this code!