On Tue, 14 Dec 2004, Tim Bunce wrote:

> On Tue, Dec 14, 2004 at 02:54:39PM +0900, [EMAIL PROTECTED] wrote:
> > Hi.


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

> 
> 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);

Intersting. 1) How significant, and 2) Do you think it would be worth the
reduction in legability?

> 
>       } 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.
> 

I see your point, but how much do you loose, 20 or so pushes and pops, a few mvs
per loop iteration, and how does that compare to pulling the data off the wire? 
 
And then if you factor it out, you have to replace the above code with something
that indexes into array and that would probably make the code not quite as
stright forward, but I am not totally against it; I just don't know if it would 
shave that much time off of the fetch?


> #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.
> 

imp_dbh->pg_enable_utf8 defaults to off.  This was put in as a hack until we get
full utf-8 support. So for right now, if you have utf-8 data, you can set
$dbh->{pg_enable_utf8} and get the above hackary.


Rudy

Reply via email to