Various Topics on Ruby

..dre.. ..hwa..

Florian Weber wrote:
>> Where's the problem? You have to load the files only once, so it
>> doesn't
>> matter how long it takes to parse them. CGI is no use for "real"
>> applications, use fastcgi, webrick or mod_ruby.
>
> well, but i think thats exactly the point why ruby is really hard to use
> for general web stuff..
>
> there are barely any hosters who support fastcgi, webrick or mod_ruby.
> especially since the last one is not usable for shared hosting. so you
> have to rely on cgi..

I agree, ruby support on shared servers is poor. This is one of the
reasons why I'm using a virtual server from www.vdserver.de.

> and anyways, why does it take ruby so long to load the files and compile
> it when the same would only take a fragment of it with php?

Did you really try PHP CGI with source files of comparable size (don't
forget that every file you require could itself require other files)?

I don't know exactly how the parsing mechanism in PHP and Ruby differs,
and I don't know if there is actually a difference in performance; but
I wouldn't be surprised if PHP was faster, because the language is
*much* simpler to parse than Ruby. However, I don't think it's really a
problem.

..v.. ..ramo..

Andreas Schwarz wrote:
> Did you really try PHP CGI with source files of comparable size (don't
> forget that every file you require could itself require other files)?
>
> I don't know exactly how the parsing mechanism in PHP and Ruby differs,
> and I don't know if there is actually a difference in performance; but
> I wouldn't be surprised if PHP was faster, because the language is
> *much* simpler to parse than Ruby. However, I don't think it's really a
> problem.

my experience with php seems to confirm this. php compilation is so fast
that it's okay to use PHP CGI for medium traffic and simple to medium
application complexity.

*but*, if your application needs to compile 1000+ lines of php code on
every request (e.g. you include/require several libraries, like PEAR
modules), the overhead does start to show itself (0.5-1 seconds or more
of delay).

php cgi apps seems faster since most libraries are written in C, while
Perl's (and Ruby's) are written in pure Perl/Ruby code so they need to
compile many lines of code per request. but this situation is changing
everyday that PEAR is more and more used everyday...

--
dave

..om.. .... ..ns..

On Mon, Jun 21, 2004 at 04:09:19PM +0900, David Garamond wrote:
> my experience with php seems to confirm this. php compilation is so fast
> that it's okay to use PHP CGI for medium traffic and simple to medium
> application complexity.

I'd go with this, and the statement that PHPs syntax is 'optimized'
for parsing. Actually it chokes on stuff like $obj->ary[$i]->value;
(alledgedly it's improving in PHP5, like many other things).

> *but*, if your application needs to compile 1000+ lines of php code on
> every request (e.g. you include/require several libraries, like PEAR
> modules), the overhead does start to show itself (0.5-1 seconds or more
> of delay).

True again. I often test things on an old 300Mhz box, to slow things
down to a speed where I can actaully gauge the speeds. Larger projects
like phpgroupware get extremely slow, which make you think twice
before throwing them on the big iron.

And don't forget that Ruby can be doing catchup when actually running
the code. I've seen Ruby code that was several factors faster than the
equvalent PHP code, doing a lot of throwing data around.

> php cgi apps seems faster since most libraries are written in C, while
> Perl's (and Ruby's) are written in pure Perl/Ruby code so they need to
> compile many lines of code per request. but this situation is changing
> everyday that PEAR is more and more used everyday...

And while we're talking about lines.. I had to fix the code in
SquirrelMail that encodes the headers when there's non-ASCII
characters in it. Thought that it would be easy as I'd done my own in
Ruby for another project and it was just 7 lines of code. Imagine my
surprise when I found out that it was 118 lines of PHP code. About 10
was 'extra' code for stuff related to SquirrelMail.

I couldn't resist, first I tried rewriting the function to exec
Ruby. Slow as hell, but only 19 lines. Then I ported my Ruby function
as well as I could and it ended up at 32 lines. So even if we subtract
the 10 lines, it's still the difference between 7 and 22 lines.

My own conclusion is that, while Ruby might be slow on the uptake
sometimes, it's not because it's inheriently slower.

--
Thomas
beast@system-tnt.dk

..v.. ..ramo..

Thomas Fini Hansen wrote:
> And while we're talking about lines.. I had to fix the code in
> SquirrelMail that encodes the headers when there's non-ASCII
> characters in it. Thought that it would be easy as I'd done my own in
> Ruby for another project and it was just 7 lines of code. Imagine my
> surprise when I found out that it was 118 lines of PHP code. About 10
> was 'extra' code for stuff related to SquirrelMail.
>
> I couldn't resist, first I tried rewriting the function to exec
> Ruby. Slow as hell, but only 19 lines. Then I ported my Ruby function
> as well as I could and it ended up at 32 lines. So even if we subtract
> the 10 lines, it's still the difference between 7 and 22 lines.

I know the feeling :-) Sometimes I curse while coding in PHP. Though it
does the job, PHP is really an ugly, half-baked, non-designed language.
Even Perl looks beautiful when I'm stuck with PHP. Plus they break
things (and change defaults!) between releases. IMO PHP is really an
undependable tool for large projects.

--
dave