Re: following up on speed

[Morgan McGuire <address@hidden>]

> Yes, I agree completely.  And also, once you're into that size, you
> may well find that the bottleneck performance issue for you is demand

> paging time.

The flipside of this is that for many applications with reasonable
total memory requirements, virtual memory paging can completely replace
a GC and sophisticated memory management is a waste of resources.

Consider an OS script or some other application that will terminate
after a well known time period.  I propose the following memory
allocation strategy: allocate memory as needed and drop pointers to it
when it is no longer in use.  Note that we don't GC the dropped memory,
just leak it "onto the floor".  Because of the VM system, any page
containing entirely garbage memory will be swapped out and consume only
hard disk space, not actual RAM.  With a large disk (the free space on
my PC disk is around 18G, which easily dwarfs my 32-bit address space)
the application won't run out of memory unless it eats its entire
address space.  There is no significant cost for paging because those
garbage pages are never swapped back in.

I think the Python speaker might have mentioned this at the
conference-- that "never free" is a reasonable strategy for many
scripting language applications.

-m



=====
Morgan McGuire  
morgan3d@yahoo.com


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com