Re: NSSpellChecker crashes after 64k words
Re: NSSpellChecker crashes after 64k words
- Subject: Re: NSSpellChecker crashes after 64k words
- From: Denis Stanton <email@hidden>
- Date: Wed, 13 Apr 2005 16:20:16 +1200
Hi Louis
Thanks for your help. I seem to have missed out on an earlier response
from you but I see enough of it contained in the clipping below to
realise where my error lay.
I was not managing the auto release pool at all. I'm only part way
through learning Obj-C from a book and that area hasn't been covered
yet, or at least not enough for me to see what was missing.
Simple bracketing each of my nested loops with :
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
.....
[pool release];
has solved the immediate problem. My apologies to the authors of
NSSpellChecker for implying that that code had a flaw. The failure
occurred while NSSpellChecker was in control, but it was not caused by
NSSpellChecker.
Denis
On Apr 13, 2005, at 11:02 AM, Louis C. Sacha wrote:
Hello...
I didn't mean to imply that there is a 64k hard limit to the total
number of autoreleased objects. What I meant is that any code that
does a significant amount of work without being integrated into the
runloop needs to manage it's own autorelease pool(s).
First, it isn't safe to assume that the only autoreleased objects
being created are those which you explicitly create yourself. In my
example, the code being executed in the loop
found = [checker checkSpellingOfString:testString startingAt:0];
doesn't explicitly create any autoreleased objects itself, but there
could be any number or kind of autoreleased objects being created
behind the scenes in the implementation of that method.
If the code was doing something other than busy work, it would
probably also be creating several autoreleased objects of its own each
time through the loop (as I expect the original poster's code does).
In this particular case, it's unlikely that enough autoreleased
objects are being created to hit a limit related to the total
available memory, but good management of autoreleased objects can
still have a significant effect. The peak number of autoreleased
objects that exist at any time has a direct impact on the amount of
memory that your application uses, which has a direct impact on the
speed of your code because of the hit from reading and writing to
virtual memory.
Since the vast majority of the autoreleased objects being created in a
loop like this are only used for that particular iteration of the
loop, the time spent writing that memory out to disk is basically
wasted since they will never be used again. Creating and destroying
autorelease pools does add a small bit of overhead, but at a certain
point that small cost becomes significantly less than what is required
to to deal with a large amount of virtual memory. You can use the
Activity Monitor program to keep an eye on how much real and virtual
memory is being used by your program.
Second, to paraphrase George Orwell, "all objects are created equal,
but some objects are more equal than others". As Evan's example would
eventually show, you can create a staggering number of some kinds of
autoreleased objects without causing a fatal error (although his
example using instances of NSString _would_ crash eventually). There
are however a few types of objects that have some sort of limit to the
number that can exist at one time. These types of objects are
generally related to interprocess communication, threads, etc... and
there is usually some sort of inherent limitation in the lower level
APIs that these objects are built on top of.
I would guess that the crash when using NSSpellchecker is related to
the accumulation of one of these types of objects. The spell checker
runs as a separate process, so the likely suspects would be
communication related. You can run your program from ObjectAlloc (in
the Performance Tools included with the Developer install) to see how
many of a particular kind of object exist at any particular time, as
well as the peak number and total created.
The autorelease pool that the main thread's run loop manages is
normally enough for simple event driven code, and most code is
implemented in a way that assumes that some sort of regular cleanup is
being done. If you end up doing a lot of work in a loop of your own,
it's important to make sure that this cleanup is still being done in
order to maintain the best level of performance and to avoid some of
the more obscure issues that could otherwise arise.
Hope that helps,
Louis
If what your saying is true than basically any app with 64K
auto-released objects should crash and that seems like a much more
heinous oversight than NSSpellChecker having a 64K word limit.
Have you tried this with code that just creates auto-released objects?
-Karl
On Apr 12, 2005 6:07 AM, Louis C. Sacha <email@hidden>
wrote:
Hello...
>
I don't think your problem is specifically related to
NSSpellchecker,
it's probably just that too many autoreleased objects are being
> created within your loop.
>
...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Denis Stanton
Orcon Internet Limited
(09) 480 9299
http://www.orcon.net.nz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden