Re: A Tale of Two Memory Managers (long)

From: Adrian Gallero (agallero_at_netscape.net)
Date: 06/08/04 

Date: 8 Jun 2004 02:58:12 -0700

[Snip]
> D) And then the next and most compelling argument is the tale of
> the two memory managers. It is my opinion that the reason why .NET
> can never be as performant as natively compiled code actually has
> NOTHING to do with the JITter, at all. I suspect it has everything
> to do with the .NET Garbage Collector that is so central to the
> entire framework. This is what kills performance; and relegates the
> .NET scenario to certain types of run-of-the-mill I.T. tasks where
> easily deployed and RICH FUNCTIONALITY (translated into
> "Productivity") is valued over PERFORMANCE.

[Snip]

>
> Comments? (remember not to over-quote).

I was just thinking on this the other day and I believe it might/will
be exactly the other way around. Programming with a GC is not necessary
easier than programming without it. In fact, I find it somehow more
complicated (at least to do it right), because not ALL resources are
freed by GC. So, do you need to dispose MemoryStream? Well, the only
way to know is to look at the docs. And what if you design a class that
doesn't need to be disposed, use it all around your app, maybe sell it
as a third party to the world... and later on you discover you need to
add some changes that will make it Disposable?

A solution for these 2 things (looking at the docs to know if the class
needs dispose, and later changes that might introduce the need) could
be, as has been pointed here, to wrap all calls as if you had no GC.

p:=Tp.create;
try
  dowhatever;
finally
  FreeAndNil(p);
end;

It doesn't matter if p is disposable or not. But, what is the advantage
on having GC then?

I think the reason for introducing GC is performance, not easy of use.
There was a time we had 640k (and less) of memory to access. On this
scenario, a linked list with all free blocks on your system is the
perfect solution. Now, machines come with 1GB of mem. And the linked
list begins to be a problem, I have suffered it with high traffic
delphi servers. Now, imagine a future system with 100GB of mem. I think
the approach of a linked list with all free blocks of your app would be
not really efficient there, specially on servers that run all day. You
will have a lot of memory fragmenting, and memory allocation could get
really slow. (as you have to traverse it all before allocating each
block)

GC looks like a natural solution. You get rid of the linked list, and
just have a pointer to the maximum memory address used by your app.
This scales well, doesn't matter that you have 1mb, 1gb or 1 tb, you
always need 8 bytes for the pointer. And it gets better than the linked
link approach as we go adding more memory to our system. In fact, if
you have too much memory (given that this is possible ;-) ) GC will not
run, and all memory will be reclaimed at the end of your app. (on
servers, gc might run on idle moments, for example at night)

I think the question is if this was the right moment (with current
memory around 256mb-1gb) to introduce GC, not if we will have to
introduce it.

>
> If I missed some items at the top of this message, feel free to add
> more items to list. It would be nice to capture technical arguments
> for a 64-bit Delphi Compiler in one thread....
>
> -d

I think what tears down .NEt performance is the lots of checking on
things (just turn on range checking on delphi to see what I mean) and
that 'there is no escape'. You will have your bounds checked no matter
that you know they don't need to. That's why it won't be really fast if
for example you need to draw a bitmap on the screen pixel by pixel. The
solution is to write this on a "non-checked", trusted dll, and then use
it from the system.

regards,
  Adrian.

Relevant Pages

  • Re: Memory Leak Experts!!!!
    ... > However as soon as app is restored all this memory is swapped back. ... > DataSet Dispose for example doesn't touch tables and rows. ... > free references in due time. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: out of memory
    ... that i presume automatically calls dispose. ... You normally dont stress test on dev. ... IOW, the purpose of Memory ... A good practice is to put the app first on a staging ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Simple Form to Form process
    ... memory consumption. ... What do must developers design for? ... Also, I have an app with some graphics, i've added them to a imagelist - is ... Close calls dispose but it fires the Closing ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: .net memory leak problem in exe
    ... call it's Dispose every time you're finished with it. ... >>SetProcessWorkingSetSize does not solve your memory consumption. ... My app was taking 30 MB memory(since some web services ... >>> i got .net memory leak exception. ...
    (microsoft.public.dotnet.framework)
  • Re: Using Objects from another class to decrease Mem Usage
    ... and then call Dispose *immediately* after you ... IDisposable has no effect on the memory usage if your resources are ... static void Main ... if the GC runs after DoSomething it will not touch the test ...
    (microsoft.public.dotnet.general)