Re: [Bibdesk-develop] notificationcenter hanging on dealloc

[Christiaan H. <chr...@we...>]

On Apr 30, 2005, at 8:14, Adam R. Maxwell wrote:

> This bug  
> <http://sourceforge.net/tracker/index.php? 
> func=detail&aid=1192203&group_id=61487&atid=497423> is noticeable with  
> large numbers of complex strings.  When BibItems are dealloced, the  
> NSNotificationCenter ends up hanging the program while it unregisters  
> all the objects; this is mainly due to complex strings, but authors  
> also cause a hit.
>
> Profiling with Shark doesn't show an obvious way to speed this up.  A  
> quick test to show how bad this is: open tugboat.bib (wait for it to  
> fully open), then close it; I get a >20s hang with Spin Control while  
> the document closes, on a 1.33/1GB PowerBook.
>
> I put BibDocument's -dealloc stuff in a separate thread, which keeps  
> the beachball from appearing (it's still hogging all the cpu it can  
> get, just in the background).  This seems like a dirty hack,  
> especially since it leaks a bit of memory (calling [super dealloc]  
> causes the thread to crash), but it's convenient.  Any idea how bad an  
> idea this is?  It could probably be improved by using pthreads vs.  
> NSThread.
>
> Other possibilities: try CFNotificationCenter (not toll-free bridged);  
> come up with some other way to update complex strings when the macro  
> definition changes.  Notifications are nice for this, since the macro  
> resolver doesn't have to keep track of its strings and update them.
>
> -- 
> Adam
>

Is it very slow for complex strings _not_ to keep the expandedvalue  
around? If not they don't have to update. I am also not really sure  
anymore with all the changes earlier how changes in macros are in the  
end propagated to the views, so if someone can enlighten me.

Christiaan