Comments on: Windows Sucks At Memory-Mapped IO During Startup

By: Spudd86

Spudd86 — Sat, 31 Jul 2010 20:57:32 +0000

@RobM this isn’t even getting in to loading the XUL and all that other stuff, this is purely loading native compiled code (which if you toss out XUL and js is only going to be BIGGER and so slower to load than it is now since you still need pretty much all of xul.dll since it’s got the layout engine in it, and it does HTML too so without that firefox wouldn’t be very useful… using XUL and js for app code is just re-using stuff they have to build anyway to support web pages for broweser UI and that means less native code to load and that means less of the kind of IO being profiled here)

By: Photodeus

Photodeus — Sat, 12 Jun 2010 11:24:14 +0000

Although not helpful in itself, RobM’s comment is just the common sense reaction of most readers. “Sounds like there’s too much in there, maybe many things can be optimized away.”

Thanks for providing an interesting reply with good links so we all can gain more insight into all the things the mozilla developers have to take into account.

By: Ted Mielczarek

Ted Mielczarek — Tue, 11 May 2010 14:15:47 +0000

Taras, Visual C++’s PGO certainly does do block separation, see:
http://msdn.microsoft.com/en-us/library/e7k32f4k%28VS.80%29.aspx
“* Basic Block Optimization – Basic block optimization allows commonly executed basic blocks that temporally execute within a given frame to be placed in the same set of pages (locality). This minimizes the number of pages used, thus minimizing memory overhead.
* Function Layout – Based on the call graph and profiled caller/callee behavior, functions that tend to be along the same execution path are placed in the same section.
* Dead Code Separation – Code that is not called during profiling is moved to a special section that is appended to the end of the set of sections. This effectively keeps this section out of the often-used pages.”

I know for sure that our binaries have at least some of these optimizations applied, I’ve seen the results when looking at the debug symbols we produce.

By: Sid

Sid — Sun, 25 Apr 2010 22:31:31 +0000

Oh, I see re the cache manager vs mmap. Wow, that’s just plain idiotic.

By: tglek

tglek — Wed, 21 Apr 2010 23:40:58 +0000

@RobM and @Says If you have nothing helpful to say, then don’t say it.

Firefox was never been leaner(in terms of performance and memory footprint) than it is now.

Unfortunately in order to implement a web browser you have to write an application bigger than calc.exe. Large apps are a pain(to different degrees) to load on most OSes.

All I’m doing is teaching it to play nice with specific OSes that it runs on so it can continue doing what it does, more efficiently.

As far as removing bloat goes, I believe Mozilla is on the cutting edge of software development for that. See http://ehren.wordpress.com/ for how we are getting rid of unneeded bloat.

@Paul thanks for your help.

By: Paul Betts

Paul Betts — Wed, 21 Apr 2010 22:11:43 +0000

Actually, Mac OS X has what you’re describing wrt Mm and Cm using the same cache called Unified Buffer…something (it’s been awhile), and it ends up being really bad for certain scenarios, because you’ll end up paging stuff to disk in order to free up disk cache space.

So imagine a VM booting up – it’s doing tons of reads, so lots of memory gets used for disk cache. Well, where do those reads go? To memory, so now all of the memory you’ve allocated that got paged out to service the disk cache, gets paged back in. The two systems end up fighting with each other, rather than in Windows where disk cache memory is free to be converted to allocated memory.

Also, don’t use large pages, they require the kernel to find large contiguous sections of memory to back the page, which under some systems will just fail.

If you want to fool Superfetch, it’s simple – start up a thread in the background that simply reads over the module in memory. That’ll cause the prefetcher to record that the entire module will be paged in.

However, are you *sure* you really need the entire thing? Imagine if every app considered itself important enough that it never wanted to get page faults, you’d end up with a far *slower* system overall. Superfetch is smart, it knows when your disk isn’t in use so it can page in stuff in the background.

By: Ulrich

Ulrich — Wed, 21 Apr 2010 17:31:51 +0000

Wow, yet Thunderbird loads WAY faster on my Fedora netbook than on my XP quad-core (Intel i-5) workstation at work with a “real” hard disk, not a slow netbook one.

I/O on Windows sucks SO much, it’s incredible.

By: .

Wed, 21 Apr 2010 17:00:56 +0000

Rather than Windows’ reads being too small, have you considered that perhaps your application is too big? Perhaps Firefox startup is slow due to wanting to load a XML-based javascript GUI framework when it starts up rather than being a slim, fast native application?

There are a lot of applications that load way faster than Firefox, so that should serve as an existence proof regarding where the fault lies.

By: RobM

RobM — Wed, 21 Apr 2010 16:49:39 +0000

Maybe the answer is to stop trying to load 11mb of pointless bloatware rubbish?

I remember when firefox was a lean, mean and *fast* browser. I miss those days.

By: Paolo Bonzini

Paolo Bonzini — Wed, 21 Apr 2010 13:23:22 +0000

@Rem

Even then, open+read+close would be one copy instead of zero. Theoretically (i.e. if it wasn’t for the cost of page faults) mmap-ed read-only files would be faster because the pages would be backed by the OS caches, with absolutely no memory-to-memory traffic.