Tough revprocessing question

MisterX b.xavier at internet.lu
Tue Sep 27 12:20:32 EDT 2005


Here's x's regular hard question of the day... ;)

Rev is great for 95 percent of the apps, this works ok though because you
can divide information or make it painless in a prepared way or a different
gui approach, no problem. But creating gradients, rendering images, treating
a million of anything is a severe issue when dealing with rev's processing
speed or throughput. I know, rev is not c...

So in graphical applications rev can be a real bottleneck. If you have to
treat lots of historical data for a display it's enormous time... Examples
abound but im sure drawing fractals, finding simple permutations, or
factorials, etc, the task soon becomes hours of wait for a calculation or an
image to draw. 

This has two adverse effects: Rev is unavailable and your CPU spikes to 100%
blocking other applications from operating correctly...

It's a fact that if we want to use rev in parallel while it processes
something, or lower the cpu we could add somekind of wait in the loop... And
this is where im asking anyone's opinion on how to implement this...

Here's some examples of ideas I'm thinking of...
Loop 10^10 times
  calculate
  send idle to rev -- rev receives socket messages or user clicks, etc...
then continues
end loop
or
loop 10^10 times
  if the number of lines in the pending messages < PMLimit then
    send calculate to rev in 12 ms
  end if
end loop

Problem with this is that things can get stuck, some waiting to be executed
and your loop waiting for the queue to move...

or

loop 10^10 times
  calculate
  wait 50 ms with messages
end loop

Is this possible?

The same situation applies to applications like games, simulations, graphic
or "processing-intensive" applications. If this runs, it blocks the rev
session, possibly other processes... Wouldn't it be nice to have some kind
of "Rev-OS" like runtime breathing bubble for the os or other running
stacks? It may be that osx doesn't act this way... It's severly annoying in
windows. 

When I test MoireX application which draws graphical moires and more with
500X500 paint X 4 points X 3 colors (in a special function realm), it blocks
everything including videos running in other apps! It breaks the connection
to chatrev, rev looks like a frozen-hung application.

The wise developper will say compile apps (but then I can't enhance them on
the run), run in other rev-session (but it's easy to get confused -
risky...). but what if you are developping the application and the testing
creates the same blocking process in your workflow? Running 2 sessions of
rev is not exactly handy, may require another license, etc... The point is
to allow rev to multitask (not thread alas) and do all this in one instance
of rev running alone (one 100cpu cycles sucking application at a time is
enough ;) - also create parallel tasking things is not the easiest way to
get projects done...

There's solutions to this, I know... but please don’t change the subject of
"giving rev some events back between loops or reducing cpu load... The point
is go give rev time to breath between loop (or 5 loops) so it can work
somewhat regularly (50% of the cpu would be nice)... 

Breaking down the "loop" into subhandlers doesn't really help (they can't be
threaded) and "sendeables" is maybe a problem if we "send" each subhandler
into the queue X 1000000. Using another runtime of rev is not the issue -
200% cpu used! overheating! your computer explodes in a new revolutionary
way ;)

In brief, is there a way to intervene in a task intensive loop, such that it
brings down the cpu to 50% use, yet still be 75% effective compared to when
we run all the loops uninterupted?

I sense that a stack based event list in addition to the existing global
eventqueue (pending messages) needs to be implemented for this... Is that a
valuable improvement? If you work with databases or graphics, long text
(+1MBs) or 10000 of anything you know what I mean... 

cheers
Xavier
http://monsieurx.com/rev







More information about the use-livecode mailing list