• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSSpellChecker crashes after 64k words
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSpellChecker crashes after 64k words


  • Subject: Re: NSSpellChecker crashes after 64k words
  • From: "Louis C. Sacha" <email@hidden>
  • Date: Tue, 12 Apr 2005 16:02:32 -0700

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


  • Follow-Ups:
    • Re: NSSpellChecker crashes after 64k words
      • From: Denis Stanton <email@hidden>
References: 
 >NSSpellChecker crashes after 64k words (From: Denis Stanton <email@hidden>)
 >Re: NSSpellChecker crashes after 64k words (From: Dan Saul <email@hidden>)
 >Re: NSSpellChecker crashes after 64k words (From: Denis Stanton <email@hidden>)
 >Re: NSSpellChecker crashes after 64k words (From: The Karl Adam <email@hidden>)

  • Prev by Date: Re: Detecting Double Byte Input
  • Next by Date: NSBezierPath: angle of a line
  • Previous by thread: Re: NSSpellChecker crashes after 64k words
  • Next by thread: Re: NSSpellChecker crashes after 64k words
  • Index(es):
    • Date
    • Thread