[Melbourne-pm] Still performing well..

[Daniel Pittman]

Sam Watkins <sam at nipl.net> writes:
> On Wed, May 19, 2010 at 12:26:58PM +1000, Daniel Pittman wrote:
>
>> [2]  ...unless the C version cheats and skips all the memory management
>>      overhead, by not freeing anything 'til the end of the process or
>>      something exciting like that. :)
>
> My test program keeps all the data in memory, maybe this is different from
> what you have in mind.

Well, not entirely: I just think it will make the performance curve of your
application look poor once it gets asked to process a 4GB CSV file, while
languages that do free unused memory will do a little better. :)

[...]

> That said, my test program I mentioned earlier does call strdup (malloc) for
> each string it keeps.  I don't think it calls free at all, at the moment.

That is what I meant by "cheats", because you are now comparing JVM-with-free
to C-without-free, which is not apples-to-apples.  For small data sets this
is a good trade-off, and it stops paying off as data sizes grow.

[...]

> I regard fragmentation / large blocks problem as a problem with the malloc
> model of allocation: it should be possible for the system to automatically
> relocate objects if needed.  This would entail using indexes and relative
> pointers, I believe it would not be a significant performance hit for most
> apps, given that the allocator can only move stuff when you invoke it.

It only requires indirect pointers, like the "handle" model that various
platforms have used over the years.  The cost is smaller than you might
imagine.

Alternately, use a tagged object implementation and update the source
references when you promote objects, or use a generational GC and get the same
sort of benefits without the cost of relocation at all.

        Daniel

Ideally, structure your language so you can use *any* of those techniques, or
even "never free anything", depending on the dynamic behaviour of the
application.  Which, not coincidentally, VM systems can do better than static
code systems. :)
-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons