04-20-06 11:55 PM
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
<font size="2"><font face="Arial,sans-serif">I asked some questions
earlier in the week about ns_adp_parse. I've done some research in an
attempt to answer them myself, and am presenting my result.<br>
<br>
<b>Does the current working directory change in the same way?</b><br>
It doesn't appear to.<br>
<br>
<b>How is out-of-band data handled (cookies, etc.)?</b><br>
Seems to be handled separately, so that cookies written in parsed code
still get set even if the result of the parse are tossed.<br>
<br>
<b>How is control data handled (setting encoding, etc.)?</b><br>
I am assuming the same holds true here as does for cookies.<br>
<br>
<br>
<b>How are return codes handled (returning a page not found, etc.)?</b><br>
I haven't tested the various return codes yet, since most of them won't
be applicable in the situations I have in mind. It's worth looking into
them for information purposes, though. The codes I can think of that
should be looked into are:<br>
</font></font>
<ul>
<li><font size="2"><font face="Arial,sans-serif">Normal Tcl exception
conditions</font></font></li>
<li><font size="2"><font face="Arial,sans-serif">The results of
ns_adp_abort, ns_adp_break, ns_adp_return</font></font></li>
</ul>
<font size="2"><font face="Arial,sans-serif"><br>
<b>General observations:</b><br>
There are two different aims I had in looking into ns_adp_parse. The
first was making sure it wasn't too slow to use. The second was to
allow my pages to parse "pieces" of the page, and then discard all the
output for a given piece if any errors were thrown in it's generation.
The second goal definitely seems to be accomplished, if we ignore
out-of-band data. Since such data would need to be accounted for in any
other way I tried to accomplish the goal, I don't consider this an
issue.<br>
<br>
When it came to timing how fast ns_adp_parse was, I found several facts
that caught me slightly off guard at first. Thinking them through, I
believe they all make sense. To give some detail, I timed "content
generation" for several different approaches:<br>
<br>
</font></font>
<ul>
<li><font size="2"><font face="Arial,sans-serif"><b>Direct Output</b>
- This was a normal include file, with some static html and some
ns_adp_puts.</font></font></li>
<li><font size="2"><font face="Arial,sans-serif"><b>Puts Output</b> -
This was an include file where all it's output was marshaled into a
variable (appended), and ns_adp_puts at the end.</font></font></li>
<li><font size="2"><font face="Arial,sans-serif"><b>Include Return</b>
- This was the same as "Puts Output", but using ns_adp_return to return
the data to the caller so that they can choose to output it or not.</font></
font></li>
<li><font size="2"><font face="Arial,sans-serif"><b>Proc Return</b> -
Similar to the above, but the html is generated in a Tcl proc instead
of an include file.</font></font></li>
<li><font size="2"><font face="Arial,sans-serif"><b>Parser </b>- The
most ignorant implementation using ns_adp_parse... open file, read
file, close file, parse text</font></font></li>
<li><font size="2"><font face="Arial,sans-serif"><b>Parser 2</b> -
The same as the above, but with the open/read/close steps removed.
Effectively, assuming we cache file contents once we read them</font></font>
</li>
<li><font size="2"><font face="Arial,sans-serif"><b>Parser BC</b> -
This implementation used a static block of text that was parsed whose
only function was to ns_adp_include a file. The reason for this will be
explained below.</font></font></li>
</ul>
<font size="2"><font face="Arial,sans-serif"><br>
The timings for the above methods varied slightly, but generally came
out in the following order and times:<br>
<br>
<font face="Courier New,sans-serif"><b>Name &am
p;nbsp; Milliseconds&n
bsp;
Description</b><br>
Proc Return: 101.490 &n
bsp; tcl proc returning html<br>
Direct Output: 172.705 nor
mal ADP programming<br>
Puts Output: 203.930 &n
bsp; marshaled output, single ns_adp_puts<br>
Include Return: 204.460 ns_adp_inclu
de returning html<br>
Parser BC: 207.200&nbs
p; ns_adp_parse, with byte compiling<br>
Parser 2: 459.95
5 ns_adp_parse, no file load overhea
d<br>
Parser:  
; 606.320 ns_adp_parse<br>
</font><br>
As can be seen, the Tcl proc is the fastest method by a considerable
margin. This is understandable, due to it being a byte compiled object
command.<br>
<br>
The normal adp programming method was the second fastest, which was
somewhat of a surprise to me. I was led to believe that it would be
slower than the Puts Output method.<br>
<br>
The Puts Output and Include Return methods came in around the same
speed, though they were almost always in the same order presented
above. I have been told that ns_adp_include byte compiles it's input
but it, and the byte compiled result), are string based commands,
rather than Object based. I believe this explains the slowdown involved
in using them.<br>
<br>
The Parser and Parser 2 methods came in remarkably slow. This surprise
me until I realized that the ns_adp_parse command works much like eval
in that it doesn't byte compile it's input. <br>
<br>
The Parser BC command was written in an attempt (which was successful,
I believe) to use ns_adp_parse, but still gain the speed benefits of
byte compiling. Since we are reading our content from a file, we could
minimize the amount of code that needed to be parsed each time. The
implementation used for this method was simply:<br>
<br>
<font face="Courier New,sans-serif">proc ns_adp_parse_file {filename
args} {<br>
set script "<% ns_adp_include $filename $a
rgs %>"<br>
return [ns_adp_parse $script]<br>
}<br>
</font><br>
Overall, I'm fairly happy with the results of Parser BC. I would think
it would be possible to gain even further benefits if it were
implemented in C (like ns_adp_parse and ns_adp_include). Additionally,
if they are not currently, I think all 3 of them would benefit from
being implemented as object commands as well as generating object based
command byte codes.<br>
<br>
My apologies for being so long winded. I asked the questions
originally, but I thought others might find my conclusions to be useful.<br>
<br>
Rob Seeger</font></font>
</body>
</html>
<pre>
<p>
[ Post a follow-up to this message ]
|
