On 12/11/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
I can sqeeze something from C maybe, but Tcl is a bottleneck, making
"for" loop bigger than over 200-500 iterations makes it crawl comparing
to PHP, even with Tcl files cached, still it is 2-3 times slower. I am
evaluating stuff for high performance web site and it looks like Tcl
alone makes requirements for hardware tougher as oppose to PHP to be
able reach same level of req/sec. Of course there is DB which make
things much slower, but having same DB in both environments still if
page requires some logic processing scripting language speed is important.
It would be interesting to see result of a registered proc:
ns_return 200 text/plain 0123456789
and the equivalent in C, just to get a baseline. I mean, is it basic,
raw Tcl byte-code execution speed that sucks compared to PHP? It would
also be nice to see PHP with one of the byte-code caches. No reason
you wouldn't use one in production, right?
I created a db command:
dbi_format {selct name, age from people where age > 18} {<li>%s: %d</li>}
It's ~ 20% faster than running Tcl code in the loop to interpolate the
value and build up the result. It calls the underlying Tcl 'format'
implementation, which isn't quite flexible enough to use only a single
dstring, so at the moment it constructs a row then copies it into the
result. It could be better.
This test was with a null driver -- the SQL query would actually be
something like {ROWS 2 2}, which means this is a command returning
rows, not DML, and give me 2 columns, 2 rows. Very low overhead. As I
recall, the biggest difference in execution times was the number of
rows returned. Plugging in a real Postgres driver increased execution
time, but not much. A query to Postgres for a couple of rows was
quicker than the null driver with ~ 50 rows constructed in Tcl.
You could also imagine '-pre' and '-post' switches which you would use
to prepend '<ul>' and append '</ul>' to the above example, which would
save the extra malloc and copys.
Further, you'd also want to specialise for ADP, appending straight to
the ADP output buffer rather than returning the result in the Tcl
interp, and then redundantly copying it into the buffer.
Anyway, I realise your looping example was just that, an example, but
one way to speed things up is to move them to C. OK, kinda obvious,
and in this case maybe feels a bit like cheating. What, I'm not
allowed to loop!? But it's not the biggest surprise in the world to
learn that people want to pull stuff from a data store and pump it out
as a web page. Probably 80% of what you do, in general, could be
covered by a half a dozen well tuned subsystems.
I guess it depends what you're building. You say high-performance. Is
it also complex? Is the tricky bit going to be getting high
performance and/or scaling it, or do you have a mountain of code to
write? PHP seems like such a sideways move... :-/
It would be really cool if you could do a couple of runs with sysprof,
say one with a simple registered C proc, and one with the ADP loop
above, and post the data files. You know, if you're not busy... :-)
http://live.gnome.org/Sysprof
