Re: GC performance - GC fragility

In article <47aff37e@xxxxxxxxxxxxxxxxxxxxxx>, Andre Kaufmann says...
Jolyon Smith wrote:
In article <47ad597e$1@xxxxxxxxxxxxxxxxxxxxxx>, Andre Kaufmann says...
[...]
Why should I do this as an expert?

This is an all too familiar protestation. Somehow being an expert makes
taking care of details "beneath" us?

I take care (and dare to say that I'm somewhat more experienced ;-) ).

Not sure of the relevance of that point, let alone your basis for making
that assumption. Not to mention what is is you think you are more
experienced in.

I on the other hand can confidently state that very few people are more
experienced in Delphi than I am since I have been using it before 1.0
was released (by which I don't mean Turbo Pascal, for Windows or
otherwise [although I did use those too], I mean "Delphi" - I was at a
company involved in the Early Experience Program).

But I don't see how such observations or assumptions actually
contributes to the discussion. <shrug>



I rather prefer to know the details, but having not to care about them
(permanently) during coding.

A GC takes those details away - it doesn't take care of them for you, it
removes them and replaces them with something else over which you have
no direct control so when/if the time comes that you DO have to care
about those details.... well, tough. There is nothing you CAN care
about.

You may well have to simply throw out your carefree code.

;)



Well a simple .NET application, which does nothing more than allocating
memory in an endless loop doesn't eat all the systems memory.
On my system it needs roughly 1,2 MByte.

Again, a pointlessly trivial application. Congratulations you proved
the square root of bu**er all.

On the other hand I could reference an application that was written in
native code that was perceived as experiencing performance and memory
footprint issues.

The decision was taken to port to .net to attempt to alleviate these
problems. After all, .net performance is as good as or (claimed to be)
even better than native, and garbage collection means that memory
management is taken care of for you and is highly efficient.

Result: An application with even worse performance and a four-fold
increase in memory footprint.

What can I say? Real world experience simple doesn't seem to jive with
trivial test case indications.

<gasp> Shock!

;)



An access violation may not be the most elegant failure condition but it
does at least highlight a problem in the code, and one that automated
testing procedures should identify before the code makes it out into the
wild.

I prefer to be notified about a problem immediately, than having to wait
till the access violation occurs.

Um, the access violation IS that immediate notification. In .net/with a
GC, there IS no problem because it's not (generally/easily) possible to
reference an object that has been collected in the same way that you can
reference an inappropriately freed (or not yet allocated) object without
a GC.

In a GC if you forget to drop a reference you leak memory - it's not an
error and it likely won't result in one. You just have an object kept
hanging around refusing to be collected because you didn't manage your
references properly.



Hard to describe or post complex examples in a newsgroup. ;-).

True, but contriving trivial ones is pointless.

The easier path doesn't always lead us to the right destination.


[...]
Wrong question. The real question is more complicated since it
necessarily involves knowing or asking what the particular application
in question is doing by keeping those 10 references in those 10 lists.

It may be that a reference count is required.

Yes, this would be the kind of solution for the problem I was thinking
about. Reference counting is perhaps an appropriate solution for native
applications, though might have more overhead than a garbage collection,
since an Interlocked Instruction is "quite expensive" especially if
multiple cores are involved.

Nicely snipping the pertinent point (that sometimes naively reference
counting is absolutely NOT the solution).


Attention - why should I regularly pay for something what the compiler
could do for me automatically.

Because it can't do it as well as you can. You aren't "paying" your
getting a benefit!

Well IMHO the compiler can do it better.

First of all, let's not forget that the compiler has little or no
involvement with garbage collection, that's the job of the runtime
Garbage Collector (which in turn, isn't a compiler).


if an object embeds 100 other
objects only once on the heap or on the stack. In Delphi I have to use
records, otherwise allocation a single object would result in 100
allocation calls to the heap

Not necessarily. If those allocations are truly costing you dearly then
you could implement a relatively simple custom allocation scheme for
that object that would allocate that memory for all 101 objects in a
single call to the heap.

But again, we were talking about Garbage Collection, not allocation.
We've jumped from one end of the issue of memory management to the
other. I'm not entirely sure why.


Why should I pay for it, if the compiler
can do it better ?

If you mean "faster" - see above. If you KNOW that allocating 1
instance of class B is going to trigger allocation of 100 instances of
class C, *YOU* (being in possession of this knowledge that the compiler
does not) can implement a custom allocation scheme for that specific
class.


I suppose you mean (WinForms) UI responsiveness, which is rather a
problem of the GUI layer (GDI+) than of the GC,

No, IME .net suffers performance-wise generally. Sluggish WinForms GUIS
are just the most obvious and easily mockable aspect. The other
problems are not so funny.

And the other problem is the memory footprint explosion that occurs
courtesy of the demands of the GC implementation.


If I can code a little tool, way more faster in .NET then why should I
let the customer pay for the additional time needed to code in a native
language or a highly optimized assembly coded version ?

If they are happy to, why not? If you were working to a fixed price
then I could see an argument for cutting corners, but that doesn't seem
to be what you are saying. <shrug>

And if the customer has performance/deployment expectations that are not
met by that rapidly coded tool, then the cheap up front cost will very
quickly be more than offset by the on-going costs of use.

The only reason software developers get away with it is that typically
the up front costs are the only tangible, visible costs. The costs of
use are buried in "process inefficiencies" and "productivity losses"
that are not easily pinned on any one thing, let alone on "that cheap
piece of software we bought".


Perhaps it's rather a question on eating not too much and too few, either
in the native or in the managed world.

;-)

An interesting analogy you are drawing here, but one has to wonder if
you've thought it through since it is .net applications that are
typically bloated and slothful, not the native ones.

..net could be argued as the software manifestation of "Globesity".


--
JS
TWorld.Create.Free;
.

Relevant Pages

  • Re: C++ Garbage Collector on VMS?
    ... case of a reference counting system, have a non-zero reference count) as ... to the beginning of the heap, updating the pointers to the objects as it ... (segregating allocation areas by type/size can help a lot there, ... any way with GC-controlled memory). ...
    (comp.os.vms)
  • Re: A re-announce on GCs defects
    ... It's bad for CPU/Resource intensive but memory cheap objects. ... reference counting can take up to 50% of your ... one strong references and you don't know when and where to call Dispose. ... Programmer doesn't have to worry about memory allocation. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: OOP
    ... then compact the unused memory. ... you will also see that the memory allocation increases are much faster ... than the deallocation rate. ... reference counted memory management has a major ...
    (microsoft.public.vb.general.discussion)
  • Re: C++ Garbage Collector on VMS?
    ... directly or indirectly from the stacks and global data spaces (or in the case of a reference counting system, have a non-zero reference count) as well as all the pointers to those objects. ... The GC then moves the objects to the beginning of the heap, updating the pointers to the objects as it does so. ... It does depend upon proper maintenance of the reference counts, and doesn't defragment the heap (segregating allocation areas by type/size can help a lot there, though - and can significantly speed up allocation and even construction/destruction in the process), but then it also doesn't have anything like the complexity of more powerful GC, either (which itself requires at least the discipline on the part of the programmer not to perform explicit allocations outside the scope of the GC that interact in any way with GC-controlled memory). ...
    (comp.os.vms)
  • Re: Sad Commentary
    ... Why are so many people fawning over the memory of somebody who obviously ... ill or not and could care less in any event. ... focusing efforts and resources upon treatment, ... CII assistance includes child and family assessment supported by ...
    (soc.retirement)