No i am not moving to PHP, i am just trying to to justify the reason for
some people why i am still using Naviserver/Tcl and do not want to
switch to more "modern" or popular platforms like PHP, Java, Python or
Ruby. If nothing else, the problem only arise when comparing speed, not
overall system performance or ability to scale it, just pure speed and
argument that if scripting language A can do this thing twice as fast as
Tcl, that means roughly that Tcl will require more hardware and money to
fulfill the same tasks and because both using same DB which means access
to DB almost identical in speed, the language engine will be the slowest
point. In case of hundreds and thousands requests at the same time, all
those extra CPU cycles will build up and Tcl based system will process
less requests than other and etc.....
Until i ran benchmarks i somehow got answers on all problems, but Tcl
speed somehow made me wonder. Also the language shootout page
http://shootout.alioth.debian.org/ shows that Tcl is second from the
end, Ruby is slower only from popular languages and it looks like there
is a lot of hype around it and Ruby's VM will be improved.
Getting to C language every time i need to do stuff is not an option, if
i need to process several lists in the Tcl in memory, as it occurred it
will be much slower than in PHP, if i got 100 records from DB, then
another 100 from another DB, now i need to scan 2 lists and do
something, not complex, it is just 2 different DBs, so i cannot join the
tables in one SQL. Real world example is not a problem to find.
I actually even tried to test PHP inside Naviserver, same file, it was
much slower than under Apache and .adp. I specifically chose simple
examples and no DB, i wanted to see how simple web pages are served. I
always though that Apache/PHP is slower than Aolserver/Naviserver, looks
like it is already history.
Stephen Deasey wrote:
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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Vlad Seryakov
571 262-8608 office
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
