You are assuming that the faults are not in Firefox. Firefox has lots of problems, including managing memory, unnecessary IO, etc., etc.
Feeds
105363 items (97572 unread) in 19 feeds
Friends
(1021 unread)
-
2 Star
(84 unread)
-
John Carrino
(12 unread)
-
Comments for Josh the Outspoken
(296 unread)
-
Josh (34 unread)
-
Planet Matt
(595 unread)
Build
(68091 unread)
-
MAKE Magazine
(20292 unread)
-
Instructables.com
(35006 unread)
-
Hack A Day
(5017 unread)
-
Toolmonger
(7776 unread)
Heads
(716 unread)
-
Exploration Through Example
-
Paul Graham: Unofficial RSS Feed (113 unread)
-
Stevey's Blog Rants
(34 unread)
-
Joel on Software (207 unread)
-
Gibson Blog
(239 unread)
-
Adventures in Bloggery (123 unread)
News
(27537 unread)
-
Slashdot (25203 unread)
-
Economist.com Global Agenda (1412 unread)
-
Ruby Inside
(922 unread)
fun
(207 unread)
-
Templar, Arizona
(207 unread)
Comments for Josh the Outspoken (3 unread)
-
Comment on one malloc to rule them all by Josef "Jeff" Sipek
Posted: May 11th, 2009, 1:20pm MDT by Josef "Jeff" Sipek
-
Comment on one malloc to rule them all by josh
Posted: May 11th, 2009, 12:38pm MDT by josh
Good point Matt, though you make me realize I also forgot up-front overhead (6MB for tcmalloc) and how fast memory is returned to the OS (tcmalloc is not very good about this).
-
Comment on one malloc to rule them all by Matt H
Posted: May 11th, 2009, 11:03am MDT by Matt H
You forgot about overhead per allocation. To quote google’s page:
Another benefit of TCMalloc is space-efficient representation of small objects. For example, N 8-byte objects can be allocated while using space approximately 8N * 1.01 bytes. I.e., a one-percent space overhead. ptmalloc2 uses a four-byte header for each object and (I think) rounds up the size to a multiple of 8 bytes and ends up using 16N bytes.
I didn’t find any info on TSLF’s page on overhead, but I think its important, especially for dynamic languages where the VM makes lots of small allocations