Speed v Version

[Nicholas Clark]

On Wed, Jun 01, 2011 at 11:12:48AM +0100, Dave Hodgkinson wrote:
> 
> On 1 Jun 2011, at 09:46, Dirk Koopman wrote:
> 
> > I contemplating providing "encouragement" to a customer to upgrade from 5.8.7 to something more modern. One of the overriding issues is "speed". The customer is fixated with "speed".
> > 
> > Unfortunately one of the major things the customer's clients do is "replicate" their ISAM data into databases, usually MS-SQL via DBI and DBD::ODBC. The ISAM data is always on Linux (and a few Unix) boxes. The replication is a batch process that must complete overnight. Currently it is a fairly close run thing.
> > 
> > I don't suppose anyone has done any speed benchmarking on the various perls to date? Still less on newer DBIs etc? All the customer's modules are circa 2005.
> 
> Then the version of perl is very unlikely to be the problem.
> 
> Tried benchmarking? How CPU bound is the batch process? Is there latency waiting
> for the database? Can you run the job as a parallel process?

My hunch is with Dave that perl likely isn't the biggest bottleneck, but
I don't know your code, and I'm guessing that you've already tried the obvious
things, so it may be wrong.

5.10, 5.12 and 5.14 should (on average) each use less RAM for the data
structures than the previous version, but that may be negligible performance
gain in this case, as I'm guessing that RAM isn't the bottleneck.

5.14 should use about 2-5% less CPU than 5.8 to 5.12, for the general case.
5.14 under ithreads likely shows a bigger speedup compared with earlier
versions. Moreover, if the customer isn't actually needing ithreads, but
currently has a threaded perl, then switching them to unthreaded *also* should
be a speedup. But all this won't help much if the database is really the
bottleneck.

I'd suggest

a: profiling the application under Devel::NYTProf with representative data,
   and seeing where it spends most of its time - waiting on the database, or
   actually chewing local CPU
b: if 5.14.0 is faster than 5.8.7, then plan on upgrading to 5.14.1 (which I
   think is due within a few weeks), but don't bother upgrading to any
   earlier version, as 5.8.x and 5.10.x are already end of life.
   (the Linux "vendors" are own their own now)

Nicholas Clark