[racket-dev] Embedded racket is much slower in thread 'heavy' programs

That fixed it. It is still a bit slower but it is now much closer and good
enough for me.
(0.945068359375 1.10400390625 0.961181640625)


On Fri, Dec 14, 2012 at 5:28 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> At Thu, 13 Dec 2012 22:57:54 -0800, Eric Dobson wrote:
> > I have a program which is thread 'heavy' and runs much slower in embedded
> > racket (vim) than it does in pure racket. [...]
> >
> > If I don't do in in a separate thread, then vim is comparable because it
> is
> > using the racket scheduler, and not calling scheme_check_threads. Vim
> calls
> > scheme_check_threads every bit (I think 10 times a second), but it looks
> > like not much progress is made on each of these steps. I can understand
> if
> > it was slightly slower, but a factor of over 50k is a bit too much. Is it
> > possible for scheme_check_threads to do more work on each invocation in a
> > scenario like this?
>
> Yes, I think it would make sense for scheme_check_threads() to loop
> with its current body until either one thread quantum (10ms) has passed
> or check_sleep() returns 1 to indicate that no threads are ready to
> run.
>
> Does the variant below help?
>
> ----------------------------------------
>
> void scheme_check_threads(void)
> {
>   double start, now;
>
>   start = scheme_get_inexact_milliseconds();
>
>   while (1) {
>     scheme_current_thread->suspend_break++;
>     scheme_thread_block((float)0);
>     --scheme_current_thread->suspend_break;
>
>     if (check_sleep(have_activity, 0))
>       break;
>
>     now = scheme_get_inexact_milliseconds();
>     if (((now - start) * 1000) > MZ_THREAD_QUANTUM_USEC)
>       break;
>   }
> }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121214/9ae4cbc8/attachment.html>