FW: Revolution and Task (handler) Overlap

[Heather Williams]

-- 
Heather Williams <heather at runrev.com> <http://www.runrev.com/>
Runtime Revolution Ltd.
Tel: +44 (0) 131 7184333 Fax: +44 (0)1639 830707
Ten Thumbs Typing Tutor Teach your Fingers to Dance

------ Forwarded Message
From: David Vaughan <drvaughan55 at mac.com>
Date: Sat, 9 Feb 2002 16:02:36 +1100
To: use-revolution at lists.runrev.com
Subject: Re: Revolution  and Task (handler) Overlap
Resent-From: David Vaughan <drvaughan55 at mac.com>
Resent-To: use-revolution-admin at lists.runrev.com
Resent-Date: Sat, 9 Feb 2002 17:27:05 +1100

I concur with all of Scott's comments (including his PS) and have added
a couple.
It actually sounds like a task that may need some pre-processing in
something like sed to filter requisite data into the Rev management app.

On Saturday, February 9, 2002, at 03:31 , Scott Raney wrote:

> On Fri, 8 Feb 2002 "Gary Dennis" <gary.dennis at mantissa.com> wrote:
>
>> Please forgive the minutiae [get your Latin right :-)] that follows
>> but I am looking at developing
snip
>> The test case application receives console output from multiple IBM
>> mainframe systems and filters the console data to call operator
>> attention to
>> high priority messages.    Because some of these mainframes have up to
>> 800
>> active tasks the volume can be substantial  (on the order of 5000
>> messages
>> per minute).  The average length of  each message is approximately 300
>> bytes.
>
> Multiplying those together and you end up with just log files that are
> growing by 2GB *per day*.  My first thought is that it might be worth
> investigating having those systems spew out a little less garbage ;-)
>
snip
>> At this point in the development, all the test case product actually
>> did was
>> a.) get the message buffer, b.) break the buffer down into lines (crlf
>> delimited message lines, the lf corresponds to the Rev RETURN, the cr
>> part
>> of the message is discarded)
Why? Rev knows what a line is in the different environments, and it
seems to be lines you want to process.

>>  and c.) place the  message lines AFTER a
>> scrollable field defined on a card.  After a  line limit is reached
>> (set at
>> 3000 lines), the handler would delete the FIRST line in the field.
>
> Another suggestion: if you're really dealing with a lot of rapidly
> changing data, don't even put all of it in fields.  Just put the part
> you need displayed in there and keep the rest in a variable.  Use a
> scrollbar object to allow the user to select what part is shown.
Emphatic agreement. Variables are much faster than fields.
However, if your limit is 3000 lines then why ask for the Number of
Lines in the field/variable? When the process starts, count up from one
(increment a variable) until you get to 3000 and thereafter always
discard the first line when you add another.
>
>>  I
>> discovered that in  I was using a replace for the mainframe cr
>> referencing
>> the entire buffer rather than the last character of each line. Causing
>> the
>> replace to reference the last character of each line rather than the
>> entire
>> buffer made some difference but not enough.
>
> I don't follow this part, but the "replace" command is very fast and
> shouldn't be a bottleneck unless you're doing it unecessarily (e.g.,
> do it on a section *before* appending it, rather than appending and
> then doing the replace on the whole buffer again).
Eh? I don't follow you here Scott. Surely Replace on each line as it
arrives would be faster than appending the line to the variable and then
doing a Replace which you **know** needs to work on only the second-last
character in the entire 3000 lines. Of course, it is not clear to me why
the cr is being replaced at all on that platform.
>
snip
>> Question 3.  Is there some way to cause Rev to execute one handler at a
>> higher priority than other handlers?
>
> No.
One way or another, if you are going to use one CPU to handle everything
then that is what the CPU has to do and straight through processing will
be more efficient than fiddling with priorities. Priorities = assumed
willingness to lose data/function in the lower priority tasks.
>
>> Question 4. Does the Number of lines function actually examine the
>> content
>> of the object to make the determination or is the value an attribute
>> of the
>> object?
>
> It's calculated, and so is not something you want to do a lot of.
...and you don't need to in this case. See my earlier comment.
>
>>
snip

regards
David


------ End of Forwarded Message