Fog Creek Software
Discussion Board




Memmory management

An interesting subject that was touched in this article but that needs more in depth discussion. 

There is a very thin line between not having to worry about managing memmory and not understanding the implications of managing memmory. 

My experience is that majority of developers that learned to code in Java, VB, C# etc.. do not understand the implications of memmory management, and produce either extremely inefficient or barely working products. 

I have seen implementations in Java that were quite textbook, but resulted in the bulk of the CPU capacity being taken up by the garbage collection thread.

There is a cost in allocating memmory, freeing memmory and copying data.  The "memmory managed" languages hide the work, but do not remove the cost.  And yet many who code in these languages do not understand the cost at all. 

Justaguy
Thursday, June 17, 2004

I can't remmemmber how to spell mmemmory

bop
Thursday, June 17, 2004

A funny but a pointess comment.

Justaguy
Thursday, June 17, 2004

Thoughtful too :)

Green Pajamas
Thursday, June 17, 2004

I think the majority of developers generate worthless, barely-functional code PERIOD, regardless of the language they weaned on.

The spin you put on it seems to reflect a great deal of your own personal bias toward high-level language programmers.

I think maybe you're bitter.  =)

muppet is now from madebymonkeys.net
Thursday, June 17, 2004

Depends on what you're doing...personally, even though I've always used languages like Basic, VB, Java, and most recently C#, I did take the time to learn a bit about the implications of garbage collection.  While I'm glad I know it, and it has been useful on occasion, most of the time it doesn't matter, because most of the apps I write spend 95% of their execution time waiting for the user to do something, which gives the GC plenty of time to do its thing.  Obviously it's more important if you're coding for embedded systems, hardware drivers, highly performant data-driven scenarios, etc.

I think the point of abstractions like these is so that you can learn only what you need to get up on your feet and be productive.  When the abstraction leaks and you start experiencing slow application behavior, *then* you research the GC concepts and figure out how to make improvements.  Of course this requires some broad base general knowledge, and a desire to write good apps rather than stuff that just works most of the time...

Joe
Thursday, June 17, 2004

Just make sure you're approaching it rationally.  Many of us put in quite a few hours learning C++, and hate to think a VB programmer who got up and running in just a few hours might be more productive than us.

That said, I tend to agree there is value in starting with a non-garbage-collected language, but for many types of apps the cost incurred by the GC will never be an issue.

pickle
Thursday, June 17, 2004

I guess it is one way to look at it.  Another way is that languages like this allow semi-competent people to write semi-working products.  And yes I am biased towards lower level languages.  It may not matter much if you are slaping a gui on top of an RDB, or some equivalent.  But in my line of work, I have to deal with real time, large volume  data feeds and real time analytics and value add based on those data feeds.  Sorry, Java or VB just don't hack it.

Am I bitter, maybe a little.  But only because I have had to spend a lot of time  fixing the messes left behind by semi-competent high level language hacks who left behind piles of garbage that could barely be considered prototypes, nevermind products.  But hey, it keeps me in a nice standard of living, so more power to all of those Java, VB and C# monkeys.

Justaguy
Thursday, June 17, 2004

When I skimmed this, I thought the subject was "mammary management"!

John Topley (www.johntopley.com)
Thursday, June 17, 2004

There is a large number of sites deddicated to that subject.  Want me to post a few links? :)

Justaguy
Thursday, June 17, 2004

Since my projects tend to be real-time, I don't want the garbage collection delay to affect them.  Nor do I want the memory fragmentation that occurs with multiple 'new' and 'delete' calls.

Therefore, I try to allocate each thing my program needs ONCE, and then not release it back to the memory manager.  This works very well in VB and C++.

When C++ allocates something on the stack, then de-allocates it when it goes out of scope, this is not a problem -- though I do feel there is a minor performance hit there. 

With Java I feel it is much harder  to get around the language's tendency to allocate temporary objects, then release them.  Even here, it is possible with careful coding to only allocate what you need, and keep it for the life of the program.

AllanL5
Thursday, June 17, 2004

Rampant developer incompetency is not limited to high level language users.  While it may be true that a the competent:incompetent ratio is higher in low level language land, where you have to work a little harder to get on your feet, it is by no means moron-free.

Anybody can write horrible innificient resource-intensive code in ANY language.

High level languages have their uses, and I'm sorry to take exception with you, but save for a few very specific scenarios, there isn't much you can't do with high level languages nowadays with very VERY acceptable performance.

muppet is now from madebymonkeys.net
Thursday, June 17, 2004

Actually I have seen one commercially available product written in Java that performed well, and was stable - Soinc MQ (a JMS implementation).  I have also gotten one solid product built in Java - an authenticaton and entitlement system.  Of course it is possible.  But it takes compareable expertese to what is needed to write good C++ code and compareable amount of time too.  Again I am talking about somthing with non-trivial complexity.

Justaguy
Thursday, June 17, 2004

As a programmer, you have to understand what you're doing.

You must have gone through the pains of char* in C and trying to build a decent string class in C++ before you can fully appreciate the value of the std::string class.

Like in the marine -- they first learn the ropes by sailing on a sail ship, the same design used 150 years ago, before they move on to modern-day ships. Philo could probably tell us.

Alex
Thursday, June 17, 2004

Great article -- I've been working with Windows API for 9 years now and am one of those dreaded COM programmers in NYC who get paid too much. I'm interested in the contrast between this article ("Memory management is Good") and your exceptions article ("Exceptions are Bad"). -- the two seem to me to go pretty much hand-in-hand, and exceptions are sold like mm, as a way of improving productivity. I've had mixed results with exceptions, when I structure the code properly they can be really useful, but I have frequently been too lazy and that has caused real problems. (It is nice to have "exceptions" to blame for the problems in this situation.)

Jeremy Osner
Thursday, June 17, 2004

Incompetency is not restricted to high level languages, but is easier to spot in low level languages.

As to "Acceptable Performance" well, it is subjective.  In the GUI world, if it is as fast as the human aye can see, it is good enough.  But there is a large world outside of GUI applications, where miliseconds count.

Justaguy
Thursday, June 17, 2004

"Since my projects tend to be real-time, I don't want the garbage collection delay to affect them.  Nor do I want the memory fragmentation that occurs with multiple 'new' and 'delete' calls."

That's understandable, and that's the traditional advice for embedded systems.  But you do need to qualify "real-time."  In my experience, everyone seems to classify his or own software as "real-time."  But there are levels of real-timeness.  Hard real-time constraints are one thing.  This is where you absolutely need to respond with 0.00001 seconds to a warning on the fuel pump or your rocket explodes.  Then there are the looser "I need to keep things smooth for the user" requirements of, say, video games.  Considering that numerous video games have used garbage collected scripting languages since the days of sub-100MHz processors, the expense of garbage collection can often be overstated.

"When C++ allocates something on the stack, then de-allocates it when it goes out of scope, this is not a problem -- though I do feel there is a minor performance hit there."

Now that's crazy talk.  Seriously.  What kind of performance hit are you expecting from a couple of instructions to create and tear down a stack frame?

Junkster
Thursday, June 17, 2004

Depends on how big, and how nested, and how many copy constructors get called to implement the properties of the object/class.

Of course, that's why C++ has 'references', so you don't pass by copy.

AllanL5
Thursday, June 17, 2004

Actually there is no performance hit with the stack frame at all. For built-in types, a declaration like "int x;" compiles to nothing.

Alex
Thursday, June 17, 2004

> As a programmer, you have to understand what you're
> doing.

Agreed.

> You must have gone through the pains of char* in C and
> trying to build a decent string class in C++ before you
> can fully appreciate the value of the std::string class.

Disagree entirely.  Why not say then that one needs to experience the joys of assembly before moving on to C?  Or that you need to understand all the details of how your CPU converts electrical signals into instructions?  You shouldn't *have* to know how the stuff under the hood works to do something useful.

Of course, that goal is a bit idealistic, so in the real world, you do occasionally need to dig in the muck and the mire.  What you do *need* to know is the general concepts of the architecture, so that when the time comes (and, yes, it will) that you need to break through the abstraction, you'll know where to start looking to learn what you need.

Joe
Thursday, June 17, 2004

As to "Acceptable Performance" well, it is subjective.  In the GUI world, if it is as fast as the human aye can see, it is good enough.  But there is a large world outside of GUI applications, where miliseconds count.

In Perl I can write applications that will in many cases compete with C for milliseconds-count operations.

muppet from madebymonkeys.net
Thursday, June 17, 2004

I've programmed in C++ my whole career, and I'd say that most of the time if you have gotten the hand of memory management, it is no issue at all.  Mostly you do it by forcing some level of scope on everything, pinning all of your heap allocatation to something held on the stack.  When your object goes out of scope, it cleans up everything it had allocated.  For maybe 85% of everything this is just fine, and most of the other 15% you can force to work with that sceme.  A good counted pointer takes you a long way, too.  (though, come on Boost.org, can't you package it up separately so I don't have to try to justify having the whole Boost library to my boss?)

But, after a point you begin to realize that there are great solutions you are avoiding because you don't want to mess with figuring out how to get the memory management safe.  Heck, I'm not sure I've ever put together a collection of objects without having to obsess about ownership.  And object orientation in C++ makes it worse sometimes by forcing pointers on you anytime you might want polymorphism.

Keith Wright
Thursday, June 17, 2004

"As to "Acceptable Performance" well, it is subjective.  In the GUI world, if it is as fast as the human aye can see, it is good enough.  But there is a large world outside of GUI applications, where miliseconds count. "

That is the case for a very limited number of pieces of software. If you look at the total cost of software the biggest single cost factor is the hourly rate of the programmer(s). If an environment suche as J2EE or .Net gives programmers huge chunks of ready-to-use functionality the cost of a more expensive machine to compensate for the extra CPU cycles and memory the equation is quite simple. Optimization is good, but should not be overvalued. For the $100 you can buy a lot of RAM nowadays.

Say cheese
Friday, June 18, 2004

"Why not say then that one needs to experience the joys of assembly before moving on to C?  Or that you need to understand all the details of how your CPU converts electrical signals into instructions?  You shouldn't *have* to know how the stuff under the hood works to do something useful."

I have programmed in assembly and I have done processor design and I think they where both extremely helpful.  If you understand processor design, pointers are easy since all instruction loading is really the same thing as pointers and you learn about important things like pipelining, and if you can code in assembly, you have a better understanding of what the system requirements will force your code to do, since you've directly dealt with the limitations of things like the number and size of registers, or getting stuff from memory into the processor.  There have been times that I've coded things all the way up in JAVA and I wrote the code faster because of my understading of what really was going on.

Steamrolla
Friday, June 18, 2004

*  Recent Topics

*  Fog Creek Home