Michael Herger wrote:
If it does run into problems I won't be blaming Perl, which is plenty
fast in my experience, but the slimserver coders. The speed of
software is mainly impacted by poor design decisions.
This is a general remark, not specifically targeted at slimserver.
[..]
I don't mean to imply that the current slimserver is poorly designed.
How should these to paragraphs be interpreted?
1. Slow software is IMHO usually bad programming & design
2. If SS is (too) slow, the cause *may be* bad design and not Perl (I'm
no slimserver expert)
3. I've often wondered if it wouldn't be better to split things up in
specialized modules (I may be wrong)
One of the reasons Perl is perceived to be slow is that Perl script
execution preceded by two things:
- Loading of a relatively bulky compiler
- Compilation of the source code
Using a packaged 'perlapp' bundle (as the Windows slimserver usually
does) adds the overhead of unpacking the compiler en sourcecode.
These extra operations are not required for compiled C-code so it would
seem that C-code must always be much faster than Perl. The trick is,
however, that the unpacking, compiler loading and copiling operations
are only done when the PerlApp is first started up. When the Perl code
is already compiled and running, performance can be pretty good.
Some people have experience in running cgi-bin versions of Perl scripts,
that can be very slow because on each page access the compiler must be
loaded and the script must be compiled. The overhead is very large in
this case. That's why smart webmasters use mod_perl, in which case the
Perl interpreter is part of the Apache server (like mod_php). In that
case Perl websites suddenly become pretty fast. Slower than C, yes, but
C has other disadvantages.
Slimserver is a long running daemon, which IMHO means that load and
compile overhead are mostly irrelevant.
Regards,
Peter
_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
