Tough revprocessing question

[MisterX]

I have a solution... Testing the easiest...

if you insert in your loops a casual 

 wait for 1 millisecond with messages

it will give rev breating time! 
so here's the breathing function in TAOO ;)

this wait with messages function is full of promess!

on breathe x
  if x is not a number or x < 1 then
    global gperformance
    put gperformance into x
    or
    put 1 into x
  end if
  wait for x millisecond with messages
  -- log it?
end breathe

This allows to draw a great moire while revchat continues to work.

this is definitely a step forward in virtual threading...

now I got a performance option... cool! 

any other tips welcome!

cheers
Xavier
http://monsieurx.com

> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of MisterX
> Sent: Tuesday, September 27, 2005 6:21 PM
> To: 'How to use Revolution'
> Subject: Tough revprocessing question
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage 
> your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution