[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(no subject)
From: |
Travis Griggs |
Subject: |
(no subject) |
Date: |
Thu, 22 Apr 2004 09:52:49 -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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- (no subject),
Travis Griggs <=