I second that experience. Pretty much every major C++ project I worked on I would craft a custom memory allocator that would do the core of the allocation. Usually this was middle-tier code and needed to run 27/7. Would typically go straight to the virtual memory APIs and allocate address areas where would manage allocations through a ring buffer strategy.
In addition to per performance, a worse problem in using malloc() is memory fragmentation. It's difficult to build software that runs 24/7 and relies on malloc() for bulk of its memory allocation. Is a principle reason I like using Java and garbage collection to write middle-tier software - all the garbage collectors for Java these days will have some strategy to compact the heap and keep fragmentation at bay. Is a bit ironic for me personally, but I'm currently doing some architecture research where am using zeromq. This library is written in C and though it has various language bindings, my target application is C. It's a bit painful to code in C trying to achieve things that were so easy and routine to do in Java. I'm using MingW and Eclipse on Windows and so it's pretty much comparable to C development on Linux. On Oct 3, 4:17 pm, Alan Kent <[email protected]> wrote: > On 29/09/2010 2:52 AM, Cédric Beust ? wrote: > > > A fair assessment of C++ overall, except for that bit: > > > On Tue, Sep 28, 2010 at 6:17 AM, Kevin Wright > > <[email protected] <mailto:[email protected]>> wrote: > > > Object allocation in Java is essentially free. In C++, malloc is > > expensive. > > > I don't recall malloc() (or new) ever even showing up in profiling > > traces. Ever. > > In a product I worked on a while back we got a 20%+ performance boost > only by changing the memory allocator. (It might have been more.) No > other change to the code - just replace the malloc library. So I think > it depends on the nature of the code, how multithreaded it is etc. We > found malloc was the single biggest performance impact we had. > > I did a lot of C++ programming, now mainly do Java programming, at least > when they let me! These days I tend to manage developers who now get > to do the fun stuff. > > I find the Java development environment and tools (IDE, junit, > continuous build, etc) much better and helps people be more productive. > E.g. Javadoc build into the IDE to make it quick to see what a function > does - it just saves that bit of messing around. (Note: I am talking > Linux based C++ - not .NET Visual Studio, which I have not used much.) > > C++ I think gives you a lot more control when you care about > performance, but Java is not bad. Doing a project at the moment where > we have to receive and process 3 million data structure updates per > second. Managed to get it going in Java on an 8-core server box. We > estimated 50% extra development time would have been required to do the > project in C++. Would have been lest performance risk in C++, but > longer to do properly. > > Alan -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
