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

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

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.

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.

"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.

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).

"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.

"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.

"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.

"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.