On Tue, Dec 14, 2004 at 02:54:39PM +0900, [EMAIL PROTECTED] wrote:
> Hi.
> 
> >> >http://search.cpan.org/~mergl/pgsql_perl5-1.9.0/
> >> Well,newer Pg.pm will be found here:
> >> 
> >>  http://gborg.postgresql.org/project/pgperl/projdisplay.php
> 
> >> But
> >> >> I'm working with Perl and PostgreSQL  using DBD::Pg and Pg and
> >> >> noticied that  Pg is 40% faster than DBD::Pg.
> >> I can't belive this before testing by myself.
> >> Is there anymore information about those bench mark?
> >
> > I can, for it all depends on how the benchmarking is done, and I'd 
> > have to say, who cares if Pg is 40% faster? 

I do! The DBI is designed to be very fast. Speed should never be a
reason to use something else. If Pg is really 40% faster then there
are problems in the DBD::Pg code.

> I benchmarked them (Pg and DBD::Pg) 2 or 3 years ago.
> At that time, DBD::Pg even slightly faster than Pg.
> #The result can be found this book (sorry but it is written in Japanese :))
> # http://www.amazon.co.jp/exec/obidos/ASIN/4756140580/250-7597458-9918646
> 
> I think "it all depends on how the benchmarking is done" too.
> #Maybe I should say "trust" not "believe".

Assuming that the "40% faster" relates mainly to fetching then
here's a quick review of the relevant code...

The Pg extension just does this to fetch a row:

        int col = 0;
        EXTEND(sp, cols);
        while (col < cols) {
            if (PQgetisnull(res->result, res->row, col)) {
                PUSHs(&PL_sv_undef);
            } else {
                char *val = PQgetvalue(res->result, res->row, col);
                PUSHs(sv_2mortal((SV*)newSVpv(val, 0)));
            }
            ++col;
        }
        ++res->row;

While the DBD::Pg extension does:

    for(i = 0; i < num_fields; ++i) {
                
        SV *sv = AvARRAY(av)[i];
        if (PQgetisnull(imp_sth->result, imp_sth->cur_tuple, i)) {
                sv_setsv(sv, &sv_undef);

That would be significantly faster as:
                SvROK(sv) ? sv_unref(sv) : SvOK_off(sv);

        } else {
                value = (char*)PQgetvalue(imp_sth->result, imp_sth->cur_tuple, 
i); 
                
                pg_type = PQftype(imp_sth->result, i);
                type_info = pg_type_data(pg_type);

Types don't vary between rows so the PQftype() and pg_type_data()
calls could be factored out of this inner-inner loop.

                if (type_info)
                        type_info->dequote(value, &value_len); /* dequote in 
place */
                else
                        value_len = strlen(value);
                
                if (type_info && (type_info->type_id == BOOLOID) &&
                                imp_dbh->pg_bool_tf)
                        {
                                *value = (*value == '1') ? 't' : 'f';
                        }

                sv_setpvn(sv, value, value_len);
                
                if (type_info && (type_info->type_id == BPCHAROID) && 
                        chopblanks)
                {
                        ...
                }
#ifdef is_utf8_string
                /* XXX Under what circumstances is type_info NULL? */
                if (imp_dbh->pg_enable_utf8 && type_info) {
                        SvUTF8_off(sv);
                        switch(type_info->type_id) {
                        case CHAROID:
                        case TEXTOID:
                        case BPCHAROID:
                        case VARCHAROID:
                                if (is_high_bit_set(value) && 
is_utf8_string(value, value_len)) {
                                        SvUTF8_on(sv);
                                }
                        }
                }
#endif

is_utf8_string() is defined for perl 5.8.x. That'll slow down
fetching of strings. Especially if any are long or have high bits set.

It ought not to be default behaviour as it's playing 'guessing
games' with the data without the applications permission.

        }
    }

Tim.

p.s. If anyone wants to discuss the code more then please change
dbi-users to dbi-dev in the CC list. Thanks.

Reply via email to