4 ms·

"Perl was very memory inefficient so you could often only serve 4 users at the same time, given the limited RAM available (eg. 512M - 1G). Note that Perl's spee

"Perl was very memory inefficient so you could often only serve 4 users at the same time, given the limited RAM available (eg. 512M - 1G). Note that Perl's speed was not a problem. I suspect this one has probably gone away with modern servers with massive amounts of RAM. Nevertheless using a compiled language would be better. (I later wrote a vastly more efficient framework in C)." I cannot even imagine the strange complexities of this circa year 2000 web application if it could only fit 4 simultaneous page loads on 1 GB of RAM. It's baffling, in fact. Perl isn't really memory hungry these days. Was it really that bad 20 years ago? I would be surprised if the Perl 5 interpreter wasn't in fact much leaner back then. At least my immediate impression of this bullet point is that it wasn't a programming language problem, but a software design problem.

rwmj 4y ago
Well it depends what you're doing of course. Part of the application was an email interface which I remember was a particular problem - it was likely loading whole emails into memory to do MIME parsing. But the point here is that large, slow processes gradually take over your system crowding out smaller and simpler requests. We had our own cage in a Docklands data centre, so "spinning up another server" was a weeks long process involving many people. In modern terms Perl isn't a problem, especially when you have servers with hundreds of gigabytes.
- daneel_w 4y ago
  I can safely say that it's not really an immediately impeding problem with 1 GB of RAM either. I have a bit of experience in the context as I develop and manage a very large Perl software stack that runs on a fleet of servers ranging from itty-bitty to small/medium. Some of it is inefficient CGI, some of it is FastCGI, some of it is resident in the background and some of it fires up on intervals. All of it is heavily trafficated. But, certainly, I'll concede that if the platform is completely CGI-based and for some reason is written such that there's a minimum footprint of 50-100 MB for any single invocation, then servers will be needing a bit of memory in lieu of a software rethink.
ilyt 4y ago
It was definitely a software problem. Small Perl app would take few tens of MBs max back then (and now). Also Perl FCGI existed much earlier than 2000 (looking at CPAN ~'96-97 appear to be first versions), althought obviously the code would be bit more complex than just "dump html on stdout"

rwmj 4y ago

Well it depends what you're doing of course. Part of the application was an email interface which I remember was a particular problem - it was likely loading whole emails into memory to do MIME parsing. But the point here is that large, slow processes gradually take over your system crowding out smaller and simpler requests. We had our own cage in a Docklands data centre, so "spinning up another server" was a weeks long process involving many people. In modern terms Perl isn't a problem, especially when you have servers with hundreds of gigabytes.

daneel_w 4y ago
I can safely say that it's not really an immediately impeding problem with 1 GB of RAM either. I have a bit of experience in the context as I develop and manage a very large Perl software stack that runs on a fleet of servers ranging from itty-bitty to small/medium. Some of it is inefficient CGI, some of it is FastCGI, some of it is resident in the background and some of it fires up on intervals. All of it is heavily trafficated. But, certainly, I'll concede that if the platform is completely CGI-based and for some reason is written such that there's a minimum footprint of 50-100 MB for any single invocation, then servers will be needing a bit of memory in lieu of a software rethink.

ilyt 4y ago

It was definitely a software problem. Small Perl app would take few tens of MBs max back then (and now). Also Perl FCGI existed much earlier than 2000 (looking at CPAN ~'96-97 appear to be first versions), althought obviously the code would be bit more complex than just "dump html on stdout"