Re: Speed: fwx versus mergetxt

So in your example, you took content that contained merge codes and converted it to regular VFP code, right? This means that you have to break all strings in chunks of up to 254 characters and also break lines of code so that they conform to the maximum length allowed with VFP. Obviously this is a tedious process, but in some cases it can speed things up.

Actually this is the exact same method used by FoxWeb 2 to process FWX files -- it converts them to regural VFP code. For example, the following fwx script:

A FoxWeb script can include unlimited FoxWeb
code blocks intermingled with HTML content.
VFP code can determine whether and how many
times HTML sections are inserted in the
output sent to the browser. Consider the
following portion of a FoxWeb script:

Multiplication Table (multiples of 7)
<%FOR i = 1 TO 9%>
<%=i%> times 7 = <%=i*7%> 
<%NEXT%>

Gets converted to:

Response.Write('A FoxWeb script can include unlimited FoxWeb ' + ;
CHR(10) + 'code blocks intermingled with HTML content. ' + ;
CHR(10) + 'VFP code can determine whether and how many ' + ;
CHR(10) + 'times HTML sections are inserted in the ' + ;
CHR(10) + 'output sent to the browser. Consider the ' + ;
CHR(10) + 'following portion of a FoxWeb script:' + ;
CHR(10) + ;
CHR(10) + 'Multiplication Table (multiples of 7)' + ;
CHR(10))
FOR i = 1 TO 9
Response.Write(CHR(10))
Response.Write(i)
Response.Write(' times 7 = ')
Response.Write(i*7)
Response.Write(' ' + ;
CHR(10))
NEXT

If buffering is off, then all Response.Write does is add the code passed to it, to a memory variable, which gets sent to the browser at the end of the request, or when Response.Flush is called.

FoxWeb Support Team
support@foxweb.com email

Sent by Joe Cosby on 01/21/2003 07:50:09 AM:

Well as a benchmark, I basically took something like

<html><body>Some stuff <<SomeMergedStuff>> more stuff</body></html>

and replaced it with

'<html><body>Some stuff ' + SomeMergedStuff + ' more stuff</body></html>'

The case in point was a page that was huge, 7 meg. (Obviously 7 meg is an unreasonably large web page any way you look at it, but sometimes things just work out that way)

Anyway it worked out to be 38 times faster the latter way.

I mean, 7 meg is huge, and when our users were generating pages that large and getting timeouts our basic reaction was "well, 7 meg is way too large a page, sorry". But it was taking the Foxpro merge something like, if I recall correctly, 4 or 5 minutes. That seems like a long time to move 7 meg of data from point a to point b.

If I could speed up the process by a similar scale, there are other parts of our system that would benefit immensely. As you say though, while it's relatively straightforward to do for merging variables, it's a problem for dynamic function calls ( <<CallMyMergedFunction()>> ).

Sent by FoxWeb Support on 01/20/2003 05:19:54 PM:

Actually MergeTxt is based on VFP's merge functionality, which is pretty fast. Although it relies on sending the output to a file and then reading the file back into the html_out variable, it's (surprisingly) almost twice as fast as VFP 7's new TEXTMERGE function, or even the new TEXT TO MEMVAR option.

What do you mean by hand-coded replacements? Are you referring to the use of STRTRAN? We have seen STRTRAN be really slow with large amounts of data. In such cases we have used the RegExp object, which is part of Microsoft's scripting library. The problem with STRTRAN and RegExp is that there's no real expression evaluation, so you can only cover a relative small number of replacement tags.

FWX scripts use totally different technology than MergeTxt. With FWX scripts, FoxWeb converts the script to a regular PRG file and inserts calls to Response.Write as necessary. Performance will vary between the two methods and will depend on the size of your HTML output, the number of replacements and the relative speed of your CPU and your hard-drive. We recommend that you run tests with your own scripts to determine which method will work best for you.

FoxWeb Support Team
support@foxweb.com email

Sent by Joe Cosby on 01/20/2003 12:13:43 PM:

Has anybody who was using Foxweb 1.x and upgraded ever tested the speed comparison between mergetxt and the fwx approach used in the newer versions?

We are in the midst of upgrading from 1.x . I was working on replacing the mergetxt with something faster, mergetxt seems to be fairly slow with large pages. I have been able to replace it with hand-coded replacements and in some cases they were as much as 30-40 x faster.

If the fwx approach is significantly faster already though, I could just switch to that and save myself a lot of work

Thanks for any responses