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