× 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.



Nathan, it appears that your CGIDEV2 sample code is returning with LR on.  Based
on your notes, it also appears not to be running in a named activation group.
If so, this puts CGIDEV2 at a significant,  unnecessary, and unfair
disadvantage.

When CGIDEV2 CGI programs return with LR off and run in named activation groups,
their externally described HTML is cached along with all the internal tables,
offsets, etc., built from that HTML.  Also, the files in both the service
program and the application remain open, etc.  Second and subsequent calls to
the same CGI program run much faster than the first.

For example, I just ran the sample program TEMPLATE4 on a good sized model 170
(1090 CPW).  The first execution took .481 seconds.  The second, using the
refresh button, took .033 seconds, 14.5 times faster.

It can be made even faster by turning off all debugging output by running the
SetNoDebug(*on) subprocedure.  When I did this with TEMPLATE4, the first
execution was .113 seconds; the second was .020.  The .020 time is 24 times
faster than the first execution with debugging on.

In your site's developer notes for CGIDEV2, you said "By running the Easy400 CGI
program in a named activation group, and returning without *INLR = *ON, the
performance improved a bit."  I'm sure most people would agree that that 14.5
times (24 times without debugging output) is more than "a bit."

Perhaps your observation occurred because your program is spending a significant
portion of its time in the dbReport subprocedure (or program), thus masking
CGIDEV2's performance improvements on the second and subsequent executions.

I would guess that CGIDEV2 programs that are properly written for performance
would significantly outperform similar Net.Data macros, especially when there is
significant procedural logic as opposed to simple set operations.   Further, I
believe CGIDEV2 performance, again when properly written, is more than
competitive with most other iSeries web serving packages and custom CGI
programs.

Also, note, that the current CGIDEV2 version supports multiple HTML files (up to
127) in the IFS.




Mel Rothman
CGIDEV2 Author
IBM eServer iSeries Custom Technology Center (iCTC)
Rochester, Minnesota





"Nathan M. Andelin" wrote:
>
> > Net.Data is a VERY robust web programming language,
> > it's just not the fastest kid on the block.  Raw CGI programs
> > (see www.easy400.ibm.it) are really slick...
>
> I agree that Net.Data is not the fastest kid on the block.  But I think it
> performs better than Easy400 CGI.  I built three (3) versions of a small
> application.  One with Net.Data.  Another with Easy400 CGI.  And another
> with my product, Relational-Web.  Each version receives the same input, and
> generates the same output.  The Net.Data version outperforms the Easy400 CGI
> version by more than double.
>
> If you'd like to review the source code for each version, see:
>
> http://www.relational-data.com/products/rweb/cgi/mainfs.htm
>
> Good luck,
>
> Nathan M. Andelin
> www.relational-data.com
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.