discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memory surprise; help a struggling newbie


From: Travis Griggs
Subject: Re: memory surprise; help a struggling newbie
Date: Thu, 22 Apr 2004 09:05:23 -0700
User-agent: Mozilla Thunderbird 0.5 (X11/20040321)

Richard Frith-Macdonald wrote:

The problem is that you are never releasing the objects you are
creating.
When the documentation says an object is autoreleased, what it means is
that it is set up to be released when the current autorelease pool is
destroyed ... if you never release the autorelease pool then the
objects in it are never released.

Thank you, things cleared up after this. The documentation made it sound like it was hell of a lot more automatic/elegant than it is. I feel both enlightened and dissapointed at the same time. :)

For normal GNUstep applications, you generally get away with ignoring
the issue since everything is even-driven, with all code executing
within callbacks or notifications sent by a run loop, and the run loop
creates and destroys autorelease pools enclosing each event.

When I saw docs that said this is usually managed by the UI/etc. framework, I got the impression that it created one for the life of your program... not on each "unit of work." So I basically have to find suitable "unit of work" points in my program to enclose with this type of stuff.

If your code is not operating in this sort of situation, you need to
create/destroy the autorelease pools yourself.
eg. at the start and end of the addEntriesTo() function.

This worked well. The code no longer grows. :) Thank you.

<subject change snipped>

Probably the difference is that the objc code is using unicode strings
and the smalltalk code is not ... that on its own would likely produce
a factor of two difference.

Nope. Not even. Smalltalk has been unicode strings for a good while now. They're pretty good about polymorphically representing with the least amount of bytes as possible, but it's all unicode interface.


Then there is the fact that you are using/misusing the autorelease
mechanism ... it's convenient, but not the most efficient way to code. Rather, you should use explicit retain/release where you can (and
certainly inside loops that are executed many times).

Fair enough. Kind of. In Smalltalk, I don't write ANY bit of memory mgmt code. So I do think it is fair to use what automatic memory mgmt features the objc environment offers, to simulate doing the same sort of task. If, I'm not using those facilities correctly, then yes, I'd expect that any performance measures are called into question. Having fixed the ARP stuff though, it still takes 97 seconds to VW-ST's 55.

Arguably, I'm comparing apples-to-oranges still though. The ST code has the benefit of just sending printString to an Integer object (pretty straightforward how to make a string out of a known integer quantity) and concatonates it with another string. Any xprintf style routine has to parse through the template, branch on the interpretation type, etc. So this is arguably more complex. OTOH, it is the first tool an application programmer would reach for to solve the problem, so maybe its not so apples-n-oragnes.

eg. for high performance with non-unicode strings you could do -

sprintf(buf, "key%d", i);
key = [[NSString alloc] initWithCString: buf];
[theDictionary setObject: staticString forKey: key];
RELEASE(key);

I compromised and used:

  char buffer[10];
  sprintf(buffer, "key%d", i);
  NSString* key = [NSString stringWithCString: buffer];
  [theDictionary setObject: staticString forKey: key];

This I think preserves my desire to use the mem-mgmt facilities, but do it as quick and fast as possible. In this configuration, the two implementations are neck and neck.

--
Travis Griggs
Objologist
Key Technology
Achille's Heel?!?! What about "Goliath's Forehead"

-----------------------------------------
This email message is intended only for the addressee(s) and contains 
information that may be confidential to and/or copyrighted by Key Technology.  
If you are not the intended recipient, please notify the sender by reply email 
and immediately delete this email.  Use, disclosure or reproduction of this 
email by anyone other than the intended recipient(s) is strictly prohibited.  
Any views expressed in the email are those of the individual sender unless the 
sender expressly states them to be the views of Key Technology.  No 
representation is made that this email or any attachments are free of viruses.  
Virus scanning is recommended and is the responsibility of the recipient.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]