× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hmm...

I was taught that the number of CPU seconds from the job log of a batch
submission was a pretty good benchmark for something like this because
there's no disk I/O.  Were they wrong?

> -----Original Message-----
> From: bmorris@ca.ibm.com [mailto:bmorris@ca.ibm.com]
> Sent: Wednesday, October 25, 2000 2:48 PM
> To: MIDRANGE-L@midrange.com
> Subject: Re: Tracing Programs
> 
> 
> 
> >Date: Wed, 25 Oct 2000 12:30:18 -0700
> >From: Chris Bipes <chris.bipes@cross-check.com>
> >
> >I have a current string parsing routine that loops thru an 
> array.  I have
> >rewritten it to use the C function StrTok.  What I want to 
> do is see if
> this
> >is really faster than the old loop.  I can also use the scan 
> and substr
> BIFs
> >to achieve the same results.  Since this is a major time critical
> >application I want to use the most efficient way possible.  
> I do not have
> a
> >dedicated machine to test on so using job timing does not 
> work.  How can
> one
> >trace the CPU time used for each transaction?  I have seen 
> machine traces
> >before that showed the machine instruction trace of a job.  
> Where do I
> find
> >this?  I am on V4R4.
> 
> Chris, even without a dedicated machine, you should be able 
> to test this.
> Create two programs each containing just the two versions of 
> the code, in a
> loop (make sure the code within the loop is just what's 
> needed to do the
> tasks
> being compared - no unnecessary calls etc).  Have the loop 
> iterate enough
> times for the program to run at least 5 minutes.  For this 
> type of program
> I always pass the number of times in as a parameter (a 
> perfect use for a
> 15,5
> parm :).
> 
> To reduce the effect of other jobs, run the programs 
> alternately 3 or 4
> times.
> Don't be tempted to take an average of the times taken for each case;
> instead
> you should compare the best times for each case.  (If the times vary
> wildly,
> you're right and I'm wrong and you'll have to find another way ...)
> 
> To increase your satisfaction that your tests are accurate, 
> try doing the
> tests like this (assuming 10000 lets your programs run at 
> least a couple of
> minutes):
>   call pgma  10000
>   call pgmb  10000
>   call pgma  50000
>   call pgmb  50000
>   call pgma 100000
>   call pgmb 100000
> 
> If pgma's times are x 5x and 10x and pgmb's times are y 5y 
> and 10y, then
> you
> can be quite sure that it's reasonable to compare x and y.
> 
> Barbara Morris
> 
> 
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.