Is Perl-DBI Slow?
Llc
Perl being an interpreted language?
Ron Reidy
your Perl code.
You network might be slow, or your database instance might be badly
configured, or you application design might be bad, or you might write
bad queries. This could make it appear that Perl is slow. Do not be
deceived, Perl is fast.
--
Ron Reidy
Lead DBA
Array BioPharma, Inc.
This electronic message transmission is a PRIVATE communication which contains
information which may be confidential or privileged. The information is intended
to be for the use of the individual or entity named above. If you are not the
intended recipient, please be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. Please notify the
sender of the delivery error by replying to this message, or notify us by
telephone (877-633-2436, ext. 0), and then delete it from your system.
John Scoles
http://www.xs4all.nl/~hmbrand/dpws2006/prfo.html
Brian D Campbell
I would say that embedding SQL in any programming gives you flexible and powerful access to your database. But that other techniques and tools could give you faster performance in specific narrowly-defined situations (e.g. a bulk data loading tool to load data from a file).
Also, in DBI, as with many large packages, there are many ways to do the same thing. Package features can be used sub-optimally. The following link provide advice on how to use Perl-DBI optimally:
http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/index.htm
Will Rutherdale
use it.
I've seen database update code written another way that is very slow:
namely, to write shell scripts and repeatedly invoke the command-line
tool (e.g. dbaccess in the case of Informix).
Perl DBI is several orders of magnitude faster than the shell approach
for a number of reasons. (A) Perl is faster because it is compiled
(*). (B) Fixed socket connection to the DB is much more efficient than
repeatedly loading the command-line tool. (C) Data structure
capabilities in Perl mean more data can be cached and you don't need to
keep hitting the disk.
Perl is nearly as fast as embedded C code but not quite. As someone
else mentioned, bulk load operations written in C can beat Perl.
However for general mixed database work you get a lot of flexibility
without much performance hit.
(*) I notice you said Perl is interpreted. This is not true. Perl
uses compile-on-load. It compiles to a virtual machine, just as Java
does, and therefore is not quite as fast as a native code compiler, but
a lot faster than interpreted code.
-Will
> -----Original Message-----
> From: LLC [mailto:ke...@kevinkempterllc.com]
> Sent: Wednesday 14 June 2006 13:12
> To: dbi-...@perl.org
> Subject: Is Perl-DBI Slow?
>
>
> I've heard that perl-DBI is slow. Is this true? If so, is it
> because of
> Perl being an interpreted language?
>
>
- - - - - Appended by Scientific Atlanta, a Cisco company - - - - -
This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
Mladen Gogala
> I've heard that perl-DBI is slow. Is this true? If so, is it because of
> Perl being an interpreted language?
>
If we are talking about DBD::Oracle as Ron suggests beneath, then
DBD::Oracle is slow. It doesn't support array interface, bulk load or
TAF. Using DBD::Oracle will impose a heavy performance penalty if you
plan on using it for extraction or load. Basically, DBD::Oracle doesn't
support any advanced features of Oracle RDBMS and is outdated, useless
junk. If you can avoid it, I advise you to do so.
--
Mladen Gogala
http://www.mgogala.com
Mladen Gogala
> No true. The DBD::Oracle module essentially is a Pro*C "wrapper" around
> your Perl code.
Really? How do I do array interface, say, for loading things into the
database? OCI can do that. Can DBD::Oracle?
Mladen Gogala
> Perl is nearly as fast as embedded C code but not quite. As someone
> else mentioned, bulk load operations written in C can beat Perl.
Actually, anything utilizing array interface can beat Perl, as far as
Oracle is concerned. DBD::Oracle is a toy-like junk which doesn't support
any advanced Oracle feature like bulk load, array interface or TAF.
Python cxOracle module can easily beat Perl. DBD::Oracle is a proof of
concept software. If you use it in places where heavy duty performance
is needed, you're in trouble.
sco...@pythian.com
a toy as it doesn't use the native OCI array interface why don't you
get of your butt and help in the development work.
http://svn.perl.org/modules/dbd-oracle/branches/array/DBD-Oracle-executearray.ZIP
Above is a the URL to the latest branch version of DBD::Oracle which
has OCI array interface support. You seem to be of the opinion that
you are an expert on it so why don't you share some of your vast
experience and help out the community in developing it rather than
complain about not having it.
The above code need some good testing you seen well poised to do some.
cheers
Mladen Gogala
> Instead of harping over and over and over again how Oracle::DBD is just
> a toy as it doesn't use the native OCI array interface why don't you
> get of your butt and help in the development work.
So, software is just a toy because I am not involved? I'm somehow to blame?
As an Oracle DBA, I'm used to being blamed for many things but this is the
the most extreme thing I've ever been accused of. I confess all my crimes,
whether I committed them or not, whether I even knew of them or not.
I wasn't mentioning names, I didn't blame anybody, I just pointed out that
software doesn't support some basic things that almost any other software
does support. The OP asked a question, I responded to the question. I was
just being a nice guy and here is the thanks I get! DBD::Oracle doesn't
support:
1) Array interface
2) Bulk loads
3) TAF
Those features are more or less standard for software that supports Oracle
which means that DBD::Oracle doesn't live up to that standard. It's as
simple as that. As I've said before, I accept my guilt and the fact that
this is so because I didn't get involved. A sin can be committed by word,
action, thought or omission. My sin is apparently one of omission. Mea
culpa, mea culpa, mea maxima culpa. I am also to blame because I said
that the emperor has no clothes.
>
> http://svn.perl.org/modules/dbd-oracle/branches/array/DBD-Oracle-executearray.ZIP
>
> Above is a the URL to the latest branch version of DBD::Oracle which
> has OCI array interface support.
Great! Please, by all means, let me know when a usable driver is available
for download on CPAN. In the meantime, take a look at this, if that helps:
http://us3.php.net/manual/en/function.oci-bind-array-by-name.php
All that I'm interested in is a driver that I can use for large
loads/unloads. I may or may not get it, but I reacted to the claims that
"DBD::Oracle" is fast. So far, it isn't. That's obviously my fault. I'll
say a rosary and my sins will go away. As a matter of fact, I'm already so
penitent and contrite that my sins are probably already gone. Hopefully,
the driver will become faster, too.
Steven Lembark
-- LLC <ke...@kevinkempterllc.com>
> I've heard that perl-DBI is slow. Is this true? If so, is it because of
> Perl being an interpreted language?
Perl is compiled, always has been.
DBI is no slower than any other application that has to
talk to a database. This involves disk and/or network I/O,
transaction processing, and any latency involved in using
a time-shared system (just about all of them these days).
I have worked on large datasets with Perl using DBI for
years; in most cases my Perl runs no slower than C that
"real" programmers come up with and frequently runs faster.
--
Steven Lembark 85-09 90th Street
Workhorse Computing Woodhaven, NY 11421
lem...@wrkhors.com 1 888 359 3508