Heh.  Java is a memory pig.  That, however, is the nature of the beast.  Sun effectively sacrificed memory for portability.  As average system memory increases, that decision (as long as they can hold the jvm size stable) looks smarter and smarter.


At this point I've run the poller for 24 hours.  It is slowly increasing in size.  About an extra 150 KB per hour on average.  Personally, I find this extremely irritating.  I am guessing that over time I have gotten complacent about variable useage.  The basic assumption at this point among Java programers is that the compiler will deal with efficiency.  For the most part this is true.  This is an object lesson for me to not rely soley on the compiler for effeciancy.


My next patch will focus on minimizing the memory footprint.  I am going to comb through the code, and look for ways to reduce variable instantiation.  I am going to not load the audio clips into memory, but instantiate them when needed.


Since the game works in UDP I think that the ideal of making the poller work in TCP/IP, as a back up to the UDP code, is dumb.  So I was also considering deleting that code.  That will mean fewer variables and an overall simpler, easier to maintain, program.



> Message: 2
> Date: Tue, 19 May 2009 15:07:41 -0500
> From: Bob Tanner <basic at us.netrek.org>
> Subject: Re: [netrek-dev] Netrek Game On! memory usage issue
> To: netrek-dev at us.netrek.org
> Message-ID: <guv3id$1ba$1 at ger.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> On 2009-05-19 09:49:36 -0500, Jeremy Shupe 
> <jeremy.shupe at gmail.com> said:
> > All told, however, I can not understand how the program might have swelled
> > to 300 megs of memory usage. I am trying to do a methodical analysis today,
> > tracking memory usage over time. So I'll look at those results tonight.
> Lots of details missing from my irc discussion. :-)
> I never said the program (poller) leaked memory or there was anything 
> wrong with the poller.
> I just stated that the JVM when running the poller takes 300M. I 
> further stated that I think the Swing to Cocoa bridge is what is the 
> memory pig (not the poller).
> I have not done any testing. As far as I know 300M is the base memory 
> footprint for the JVM under osx.

Hotmail® goes with you. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090520/bc6f3c0c/attachment.htm