[Openmcl-devel] thread overview

[Hamilton Link]

Gut or no gut, it's not hard to introduce 300-500ms in naive lisp code 
that's not caching when it should. As an example I am doing some 
Bayesian belief propagation stuff, and after I memoized everything I 
was naively recomputing I saved myself about 138 seconds per round of 
EM -- reducing it to 6 seconds from 144.

I would be a little surprised if there was a Mac OS issue here... 
particularly because in a fresh cocoa listener window there is no 
perceptible delay, while in a medium-sized lisp file there's a big 
honkin' delay. Cocoa issues wouldn't be affected by the file size, 
where the rest of this could. On the other hand, maybe it's just much 
easier for Cocoa to figure out what to be redrawing when the whole text 
wrapper object is smallish.

We'll see. I will spend some time looking as well, I'll do some 
profiling of Gary's suspects to start with. Where in the lisp by the 
way are you looking, again? I'd like to profile those points as well.

thanks,
hamilton

On Aug 23, 2004, at 9:23 AM, alex crain wrote:

>
> On Aug 23, 2004, at 12:20 AM, Gary Byers wrote:
>>
>> Etc., etc. ... Context-switching isn't free, but I think that a modern
>> CPU can switch contexts faster than you can type.  I don't think that
>> the fact that two threads are involved is as likely a culprit as the
>> fact that some of the things those threads are doing is grossly 
>> inefficient
>> is.
>>
> I've been digging a lot, and I suspect that neither of these answers 
> is correct.
> I don't think that context switching is an inherent problem - the CPU 
> should easily
> be able to context switch several hundred times per second - and while 
> the "linear string"<->"linked list of lines" code can probably be made 
> more efficient, there is a 300-500mS delay with every keystroke and my 
> gut says that the coding isn't responsible.
>
> I'm thinking that there is a built in delay somewhere that is being 
> missed - maybe something in the cocoa window update update code that 
> is causing the wait.
>
> I played around a little bit, and the delay happens well after the 
> character is passed to the "Self Insert" command code and the buffer 
> is updated on the hemlock side. I'm thinking somewhere on the cocoa 
> side, maybe the buffer update notification is taking awhile to get to 
> the hemlock window thread.
>
> :alex
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>