On Fri, 14 Sep 2001 12:05:05 +0200, Peter J . Holzer wrote:
>I don't trust the Benchmark module, though. It reported one negative
>"wallclock secs" value at every run, and the wallclock and usr times
>differ too much for a test which should essentially take 100% user time.
Are you saying you wan
I modified Peter J. Holzer's code to test both the case where the
$i is set to 1 (Holzer's case) and where $i is 0 (which forces
more assignments). I also added a straight assignment
statement to each set. The program and results are below.
This test was run three times on a Sun Ultra 5, with So
On 2001-09-13 17:01:20 -0400, Rob Ransbottom wrote:
> On Thu, 13 Sep 2001 [EMAIL PROTECTED] wrote:
>
> > I have a minor optimization suggestion. Instead of this:
>
> > unless ($sth_routine_name) {
> > #setup statement handle
> > }
>
> > Do this:
> >
> > $sth_routine_name ||= $dbh->prepare
On Thu, 13 Sep 2001, Tim Bunce wrote:
> On Thu, Sep 13, 2001 at 05:01:20PM -0400, Rob Ransbottom wrote:
> > Talk about infinitesimal differences.
>
> Exactly. I'd rather spend my time on the bigger performance issues
> and then, if there's any time left over, go and have a beer...
I agree in th
On Thu, Sep 13, 2001 at 05:01:20PM -0400, Rob Ransbottom wrote:
> Talk about infinitesimal differences.
Exactly. I'd rather spend my time on the bigger performance issues
and then, if there's any time left over, go and have a beer...
Tim.
On Thu, 13 Sep 2001 [EMAIL PROTECTED] wrote:
> I have a minor optimization suggestion. Instead of this:
> unless ($sth_routine_name) {
> #setup statement handle
> }
> Do this:
>
> $sth_routine_name ||= $dbh->prepare();
> pretty sure this is more efficient than setting up the unless b
EMAIL PROTECTED]
cc:(bcc: Wesley Sheldahl/Lex/Lexmark)
Subject: Re: undef & NULL
In my modules, I will:
my $sth_routine_name;
sub routine_name{
unless ($sth_routine_name) {
#setup statement handle
}
#use statement with @_ params
}
> > I
Thanks to all for the helpful ideas.
Now I'm edjic^H^H^H^Hjdic^H^H^H^H^H learned.
On Thu, 13 Sep 2001, Philip Newton wrote:
> Yes; I do that frequently. That's really why there's a difference between
> preparing and executing; I usually prepare all the statements I will need at the
> beginning o
On Wed, 12 Sep 2001 13:59:49 -0400 (EDT), [EMAIL PROTECTED] (Rob Ransbottom)
wrote:
> Has anyone tried caching the prepared statements?
Yes; I do that frequently. That's really why there's a difference between
preparing and executing; I usually prepare all the statements I will need at the
beg
On Wed, 12 Sep 2001, Bart Lateur wrote:
> Rob Ransbottom wrote:
> >With the below code, with PostgreSQL, with Perl 5.005.
> >I wish to map Perl's 'undef' to SQL's 'NULL' but get the
> It's a good thing perl gives you that warning, because this code snippet
> won't do what you want. In fact, if
On Wed, 12 Sep 2001 01:21:06 +0200, [EMAIL PROTECTED] (Bart Lateur) wrote:
> What can you do? I *think* placeholders do the right thing
I believe so, too. Use placeholders. Placeholders good.
They save you from having to quote interior quotation marks, they handle NULLs
correctly, they're bette
On Tue, 11 Sep 2001 16:26:13 -0400 (EDT), Rob Ransbottom wrote:
>With the below code, with PostgreSQL, with Perl 5.005.
>I wish to map Perl's 'undef' to SQL's 'NULL' but get the
>warning
>
> Use of uninitialized value at /home/rir/Rbks/Lib/Dept.pm line 26.
>
>when passing in a hash object like
eptember 11, 2001 4:26 PM
> To: [EMAIL PROTECTED]
> Subject: undef & NULL
>
>
>
> With the below code, with PostgreSQL, with Perl 5.005.
> I wish to map Perl's 'undef' to SQL's 'NULL' but get the
> warning
>
>Use of uninitialized
With the below code, with PostgreSQL, with Perl 5.005.
I wish to map Perl's 'undef' to SQL's 'NULL' but get the
warning
Use of uninitialized value at /home/rir/Rbks/Lib/Dept.pm line 26.
when passing in a hash object like:
{ dept => "somestring", descr => undef }
This is proper perl beh
14 matches
Mail list logo
