www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Has anyone experienced performance problems with the GC?

reply Brad Beveridge <brad somewhere.net> writes:
I ask because many people seem to assume that because D has a GC, there 
will be catastrophic pauses, performance issues and bats flying out of 
your computer.

Has anyone actually experienced GC performance issues in their 
applications?  If you did, are you please able to explain the situation 
and what you did to overcome the problem?

Brad
Jun 24 2005
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Only with ridiculously large arrays, and that was with an older version. 
  I haven't tested it lately, although I doubt it's still a problem as 
it was only on shutdown, and now the GC doesn't do a scan on shutdown.

IMHO, it would be nice if new for a class and new for a byte array were 
different.  Unless I'm mistaken, the contents of your byte array - even 
a large one - are scanned for pointers just like everything else.  But, 
even so, I've not seen much in the way of problems.

-[Unknown]


 I ask because many people seem to assume that because D has a GC, there 
 will be catastrophic pauses, performance issues and bats flying out of 
 your computer.
 
 Has anyone actually experienced GC performance issues in their 
 applications?  If you did, are you please able to explain the situation 
 and what you did to overcome the problem?
 
 Brad

Jun 24 2005
parent "Walter" <newshound digitalmars.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message
news:d9hct5$308e$1 digitaldaemon.com...
 IMHO, it would be nice if new for a class and new for a byte array were
 different.  Unless I'm mistaken, the contents of your byte array - even
 a large one - are scanned for pointers just like everything else.

You're not mistaken, that could be improved. A lot of things could be done to improve the gc performance, and I hope I can get to them.
Jun 25 2005
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Brad Beveridge wrote:
 I ask because many people seem to assume that because D has a GC, there 
 will be catastrophic pauses, performance issues and bats flying out of 
 your computer.
 

It's like the 'Java is slow' mantra (which I have seen repeated here a few times). The reality is that Java is generally only slow when you abuse it (which is what most C++ programmers do - i.e. coding Java like C++ - people do what they are used to, naturally). It's the same for GC. GC generally won't have a negative impact on your app unless you abuse it. But there's a bunch of FUD that people continue to propagate. These days, I'm more inclined to disbelieve someone who says 'such-and-such is slow', even if they back it up. Too many times I have seen people back up their arguments with meaningless microbenchmarks (often improperly measured), ouutdated experiences, or experiences with apps that were poorly written in the first place. I often get the same FUD when I talk to people about D ('yuck, GC! What a performance killer' - this from a guy who spent a few weeks testing and debugging his own custom memory manager in C++). The real test comes from personal experience. No matter what garbage I hear or read on the net, I know Java is performant because I've used it extensively. I know GC doesn't kill my apps because I've been working with GC'ed languages for a few years now. I know that neither D's lack of a good debugger nor it's lack of an STL equivalent hinder my development. Those who say otherwise can rant on and leave me be.
 Has anyone actually experienced GC performance issues in their
 applications?  If you did, are you please able to explain the
 situation and what you did to overcome the problem?

In my cause, a resounding 'no'. I haven't stressed it yet, really, but no problems so far.
Jun 24 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Mike Parker" <aldacron71 yahoo.com> wrote in message 
news:d9i0hu$k8s$1 digitaldaemon.com...
 Brad Beveridge wrote:
 I ask because many people seem to assume that because D has a GC, there 
 will be catastrophic pauses, performance issues and bats flying out of 
 your computer.

It's like the 'Java is slow' mantra (which I have seen repeated here a few times). The reality is that Java is generally only slow when you abuse it (which is what most C++ programmers do - i.e. coding Java like C++ - people do what they are used to, naturally). It's the same for GC.

This code is from old Sun's Personal Java (Now it is J2ME) distribution: (class Graphics) /** * Returns the true origin of this context, relative to the screen. * * return a Point object holding the origin. */ private Point getOrigin() { Point ptOrigin; Rectangle rcBounds; /* * Offset origin from window bounds by current translation */ rcBounds = geometry.getBounds(); ptOrigin = new Point( rcBounds.x + ptTrans.x, rcBounds.y + ptTrans.y ); return (ptOrigin); } Take a look on this 'new Point'. Each time when you need origin of coordinate system it uses .dup. ( (c) Walter :-) This the only way how to return "immutable" object - to create its copy - as Java does not have a concept of const. (No one C++ programmer in good mental health will do it, btw) GC in modern Java by itself is not that bad. But no one GC will handle such enormous stream of allocations. Just left your Java app window open on the screen ('idle') but if somebody will move window on top of it - you will get a "Joy of GC". Again, GC is not bad at all. If it is used by its purpose and not as just a strut for bad design. Speaking about Java UI. These 'new Points' are spreaded all over Java GUI libraries.
 GC generally won't have a negative impact on your app unless you abuse it. 
 But there's a bunch of FUD that people continue to propagate.

 These days, I'm more inclined to disbelieve someone who says 
 'such-and-such is slow', even if they back it up. Too many times I have 
 seen people back up their arguments with meaningless microbenchmarks 
 (often improperly measured), ouutdated experiences, or experiences with 
 apps that were poorly written in the first place. I often get the same FUD 
 when I talk to people about D ('yuck, GC! What a performance killer' - 
 this from a guy who spent a few weeks testing and debugging his own custom 
 memory manager in C++). The real test comes from personal experience. No 
 matter what garbage I hear or read on the net, I know Java is performant 
 because I've used it extensively. I know GC doesn't kill my apps because 
 I've been working with GC'ed languages for a few years now. I know that 
 neither D's lack of a good debugger nor it's lack of an STL equivalent 
 hinder my development. Those who say otherwise can rant on and leave me 
 be.

 Has anyone actually experienced GC performance issues in their
 applications?  If you did, are you please able to explain the
 situation and what you did to overcome the problem?

In my cause, a resounding 'no'. I haven't stressed it yet, really, but no problems so far.

I haven't seen no one Java GUI application which came even close to their non-GC counterparts. I mean lightweightness and speed. Andrew.
Jun 24 2005
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Andrew Fedoniouk wrote:
 "Mike Parker" <aldacron71 yahoo.com> wrote in message 
 news:d9i0hu$k8s$1 digitaldaemon.com...

 Each time when you need origin of coordinate system it uses .dup. ( (c) 
 Walter :-)
 This the only way how to return "immutable" object - to create its copy - as 
 Java
 does not have a concept of const.
 (No one C++ programmer in good mental health will do it, btw)
 
 GC in modern Java by itself is not that bad.
 But no one GC will handle such enormous stream of allocations.

This is what I mean by 'absuing the GC'. When you code /for the GC/ (and one such thing you can do is large numbers of allocations of small objects) then you most likely will not run into problems. If I ever see a GC stutter in an app, the first place I look is my code. Hopefully one day we will have some quality GC profilers for D so that we can tweak our apps for the GC as much as possible.
 
 I haven't seen no one Java GUI application which came even close
 to their non-GC counterparts. I mean lightweightness and speed.

And this is something that normally gets my goat. I've personally never had performance issues with AWT apps (other problems are a different ball of wax). Swing apps are more often than not slow and klunky. SWT is performant when you have the memory to support it, and the Netbeans platform is much better than it was in the past but still is a memory hog. But for all of this it is not anything inherent in the language that makes these applications slow. It's all of the layers of abstraction coupled with JNI overhead that hurt performance of Java GUIs (and to be fair, the IDEs I cited - which are some of the klunkiest Java apps around - also have a lot going on behind the scenes). This is what I'm talking about. You can't judge the general performance of a language based on the performance of a GUI API - there's a clear line of separation. But many people ignore that line when they talk about Java. Two of my favorite indie games on the market right now are coded with Java (http://oddlabs.com/tribaltrouble.php and http://www.puzzlepirates.com/). You most likely wouldn't even know these games were Java unless someone told you or you read the websites (the JREs are embedded in the distros). And if you had never seen a Java app in your life there's no way you would be saying 'Java is slow' after seeing these. Both games are performant (even on low end systems) and neither suffers from GC hiccups that I've noticed. And the PuzzlePirates game even uses Java2D! There's many more examples like that around the web. My intent is not to defend Java, but rather to attack that attitude people have toward it and other 'non-C' languages. Someday, someone is going to be evangelizing D and they are going to run into people who claim that D is slow, and who are going to cite such and such app as an example while refusing to believe otherwise. Sometimes there will be limitations that cannot be gotten around (heavyweight, overengineered GUI APIS), and sometimes there will be apps coded by people who are not experienced enough to know the pitfalls of GC in general and D in particular - both cases will likely result in poor performing D apps. Can we then say that D is slow? Of course, not. That's just silly. But people will do it anyway. And there will be endless debates, flame wars, rants and tirades on the net and in dev shops around the world. But while the naysayers will continue to naysay and spread their mythic tales, those who know the language inside and out will continue to knock up performant apps and reap the benefits of D,. And life goes on (much as it did for C++ when it was 'slow' because of the overhead of classes and virtual functions).
Jun 24 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Mike Parker" <aldacron71 yahoo.com> wrote in message 
news:d9ikrh$bgu$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:
 "Mike Parker" <aldacron71 yahoo.com> wrote in message 
 news:d9i0hu$k8s$1 digitaldaemon.com...

 Each time when you need origin of coordinate system it uses .dup. ( (c) 
 Walter :-)
 This the only way how to return "immutable" object - to create its copy - 
 as Java
 does not have a concept of const.
 (No one C++ programmer in good mental health will do it, btw)

 GC in modern Java by itself is not that bad.
 But no one GC will handle such enormous stream of allocations.

This is what I mean by 'absuing the GC'. When you code /for the GC/ (and one such thing you can do is large numbers of allocations of small objects) then you most likely will not run into problems. If I ever see a GC stutter in an app, the first place I look is my code. Hopefully one day we will have some quality GC profilers for D so that we can tweak our apps for the GC as much as possible.
 I haven't seen no one Java GUI application which came even close
 to their non-GC counterparts. I mean lightweightness and speed.

And this is something that normally gets my goat. I've personally never had performance issues with AWT apps (other problems are a different ball of wax). Swing apps are more often than not slow and klunky. SWT is performant when you have the memory to support it, and the Netbeans platform is much better than it was in the past but still is a memory hog. But for all of this it is not anything inherent in the language that makes these applications slow. It's all of the layers of abstraction coupled with JNI overhead that hurt performance of Java GUIs

"JNI overhead"? JNI stands for "Java Native Interface", what is wrong with it? Just wondering...
  (and to be fair, the IDEs I cited - which are some of the klunkiest Java 
 apps around - also have a lot going on behind the scenes).

 This is what I'm talking about. You can't judge the general performance of 
 a language based on the performance of a GUI API - there's a clear line of 
 separation. But many people ignore that line when they talk about Java. 
 Two of my favorite indie games on the market right now are coded with Java 
 (http://oddlabs.com/tribaltrouble.php and http://www.puzzlepirates.com/). 
 You most likely wouldn't even know these games were Java unless someone 
 told you or you read the websites (the JREs are embedded in the distros). 
 And if you had never seen a Java app in your life there's no way you would 
 be saying 'Java is slow' after seeing these. Both games are performant 
 (even on low end systems) and neither suffers from GC hiccups that I've 
 noticed. And the PuzzlePirates game even uses Java2D! There's many more 
 examples like that around the web.

 My intent is not to defend Java, but rather to attack that attitude people 
 have toward it and other 'non-C' languages. Someday, someone is going to 
 be evangelizing D and they are going to run into people who claim that D 
 is slow, and who are going to cite such and such app as an example while 
 refusing to believe otherwise. Sometimes there will be limitations that 
 cannot be gotten around (heavyweight, overengineered GUI APIS), and 
 sometimes there will be apps coded by people who are not experienced 
 enough to know the pitfalls of GC in general and D in particular - both 
 cases will likely result in poor performing D apps. Can we then say that D 
 is slow? Of course, not. That's just silly. But people will do it anyway. 
 And there will be endless debates, flame wars, rants and tirades on the 
 net and in dev shops around the world. But while the naysayers will 
 continue to naysay and spread their mythic tales, those who know the 
 language inside and out will continue to knock up performant apps and reap 
 the benefits of D,. And life goes on (much as it did for C++ when it was 
 'slow' because of the overhead of classes and virtual functions).

Let's return back to the roots... Nobody is talking here that GC or heap or stack allocation is bad. They are good if used properly. Language shall provide equal facilities for all approaches. (I like 'delete' in D but it is just 'A') If something could be done without heap/gc allocation at all this would be just perfect. If you can return "const char[]" instead of duping it then tell me why the hell you are not doing it? --------------------------- Sidenote about Java GUI: http://www.terrainformatica.com/org/j-smile/index.htm Here is my experimental JavaVM with GUI demo running with GC (copying GC) configured to use 64k bytes only (one half). It is not allocating any memory on paint . This demo has GDI resource leakage though, mea culpa, but nevertheless it is just interpreting bytecodes using one big switch in C++ and without any JIT. Is it slow? Does it need one minute just to show initial screen.....? Ah? Andrew.
Jun 24 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d9ius8$inm$1 digitaldaemon.com...
 "JNI overhead"? JNI stands for "Java Native Interface",  what is
 wrong with it? Just wondering...

It's been many years since I looked at it, but as I recall Java cannot call C code directly. It has to run through a JNI interface which does things like reorder the parameters on the stack to match the C calling conventions. There are also issues with transferring object references due to the GC.
Jun 25 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d9j3i1$qp8$2 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d9ius8$inm$1 digitaldaemon.com...
 "JNI overhead"? JNI stands for "Java Native Interface",  what is
 wrong with it? Just wondering...

It's been many years since I looked at it, but as I recall Java cannot call C code directly. It has to run through a JNI interface which does things like reorder the parameters on the stack to match the C calling conventions. There are also issues with transferring object references due to the GC.

Reordering parameters.... It depends on direction of stack growing in particular JavaVM implementation. Main problem that you need to pass additional parameter like JNIEnv. But in my particular case: I am not using standard JNI - all native functions have the same signature: void func(JSVM* vm, void* params, void* result ). params and result are pointing directly into Java stack area. Each native function is casting params to some structure describing java parameters, so no need to reorder - direct mapping. In any case if you are treating Java as a 'glue' language/environment for native components then even standard JNI is acceptable - do in bytecode what is better to do in bytecode and in native what is naturaly native and this is it. "issues with transferring object references due to the GC" - it is problem in multithreading GC, afaik. Andrew.
Jun 25 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Mike Parker" <aldacron71 yahoo.com> wrote in message
news:d9i0hu$k8s$1 digitaldaemon.com...
 These days, I'm more inclined to disbelieve someone who says
 'such-and-such is slow', even if they back it up. Too many times I have
 seen people back up their arguments with meaningless microbenchmarks
 (often improperly measured), ouutdated experiences, or experiences with
 apps that were poorly written in the first place. I often get the same
 FUD when I talk to people about D ('yuck, GC! What a performance killer'
 - this from a guy who spent a few weeks testing and debugging his own
 custom memory manager in C++). The real test comes from personal
 experience. No matter what garbage I hear or read on the net, I know
 Java is performant because I've used it extensively. I know GC doesn't
 kill my apps because I've been working with GC'ed languages for a few
 years now. I know that neither D's lack of a good debugger nor it's lack
 of an STL equivalent hinder my development. Those who say otherwise can
 rant on and leave me be.

I was on the "explicit memory allocation is obviously faster than gc" train for many years. Until I started working with gc's. Then I discovered to my amazement that gc'd apps can actually be faster. The reasons are: 1) the code doesn't have to keep track of who owns the memory. Reference counting, for example, can be surprisingly costly. 2) often, the "keep track of who owns the memory" is done by "when in doubt, make extra copies of the data". This of course means "slow". I've found that gc'd apps tend to make a lot fewer allocations, and nothing speeds up overall memory allocation more than doing fewer allocations. 3) C's (and C++'s) idea that strings are null-terminated means slicing doesn't work, and lots of extra copies are made. Of course, it's possible to work around these problems in C++, and I've seen it done, but it requires complicated custom code, and very few ever bother.
Jun 25 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d9j452$s1b$1 digitaldaemon.com...
 "Mike Parker" <aldacron71 yahoo.com> wrote in message
 news:d9i0hu$k8s$1 digitaldaemon.com...
 These days, I'm more inclined to disbelieve someone who says
 'such-and-such is slow', even if they back it up. Too many times I have
 seen people back up their arguments with meaningless microbenchmarks
 (often improperly measured), ouutdated experiences, or experiences with
 apps that were poorly written in the first place. I often get the same
 FUD when I talk to people about D ('yuck, GC! What a performance killer'
 - this from a guy who spent a few weeks testing and debugging his own
 custom memory manager in C++). The real test comes from personal
 experience. No matter what garbage I hear or read on the net, I know
 Java is performant because I've used it extensively. I know GC doesn't
 kill my apps because I've been working with GC'ed languages for a few
 years now. I know that neither D's lack of a good debugger nor it's lack
 of an STL equivalent hinder my development. Those who say otherwise can
 rant on and leave me be.

I was on the "explicit memory allocation is obviously faster than gc" train for many years. Until I started working with gc's. Then I discovered to my amazement that gc'd apps can actually be faster. The reasons are: 1) the code doesn't have to keep track of who owns the memory. Reference counting, for example, can be surprisingly costly.

It is the same as "GC can be surprisingly costly." Can be and can be not. As an "educated GCier" I would like to have a choice. Again true is in the middle - in the balance of many approaches. Support of stack intializations (struct ctor/dtor or class stack allocations) is also here, BTW.
 2) often, the "keep track of who owns the memory" is done by "when in 
 doubt,
 make extra copies of the data". This of course means "slow". I've found 
 that
 gc'd apps tend to make a lot fewer allocations, and nothing speeds up
 overall memory allocation more than doing fewer allocations.
 3) C's (and C++'s) idea that strings are null-terminated means slicing
 doesn't work, and lots of extra copies are made.

"lots of extra copies are made." Surprisingly but in real life D slicing does not change anything here dramatically. See: class URL { char[] src; char[] domain() { return src[x..y].dup; } } const slicing is better and allows to reduce many cases of needless allocations: class URL { char[] src; const char[] domain() { return src[x..y]; } } 'const' is not ideal - it is just one more convenient tool for particular domain.
 Of course, it's possible to work around these problems in C++, and I've 
 seen
 it done, but it requires complicated custom code, and very few ever 
 bother.

Oh, yeh, any effective system requires "complicated custom code". "complicated custom code" will be always there. GC/heap does not really matter - nor GC nor heap are silver bullets. E.g. in Harmonia I am allocation HTML DOM elements manually for many reasons. Andrew.
Jun 25 2005
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Brad Beveridge wrote:
 I ask because many people seem to assume that because D has a GC, there 
 will be catastrophic pauses, performance issues and bats flying out of 
 your computer.
 
 Has anyone actually experienced GC performance issues in their 
 applications?  If you did, are you please able to explain the situation 
 and what you did to overcome the problem?
 
 Brad

No, but then I'm too afraid to let memory get too out of control, so I remember to delete my classes. I also havn't made a program that goes so crazy with memory so the GC will need to be called every 10 sec. Someday I'm going to do so, just to see how the GC handles it.
Jun 24 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
I'm just going to bump this thread.  Just in case someone who has had 
terrible GC performance has missed this topic & is sobbing in a corner 
somewhere.

Brad
Jun 29 2005
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
I think I would, indeed, be worried if anyone encountered problems 
*that* severe.

-[Unknown]


 I'm just going to bump this thread.  Just in case someone who has had 
 terrible GC performance has missed this topic & is sobbing in a corner 
 somewhere.
 
 Brad

Jun 29 2005