[postgis-tickets] [PostGIS] #2798: raster2pgsql spins CPU on statement timeout

[PostGIS]

#2798: raster2pgsql spins CPU on statement timeout
---------------------+------------------------------------------------------
  Reporter:  strk    |       Owner:  dustymugs   
      Type:  defect  |      Status:  reopened    
  Priority:  medium  |   Milestone:  PostGIS GDAL
 Component:  raster  |     Version:  trunk       
Resolution:          |    Keywords:              
---------------------+------------------------------------------------------

Comment(by strk):

 With inlined hex conversion, and line-by-line profiling:
 {{{
 Each sample counts as 0.01 seconds.
   %   cumulative   self              self     total
  time   seconds   seconds    calls  ns/call  ns/call  name
  53.88      0.63     0.63                             rt_raster_to_hexwkb
 (rt_wkb.c:697 @ 41ce8b)
  14.66      0.80     0.17                             rt_raster_to_hexwkb
 (rt_wkb.c:695 @ 41ce66)
  11.21      0.93     0.13                             rt_raster_to_hexwkb
 (rt_wkb.c:695 @ 41ce9d)
   5.60      0.99     0.07                             rt_raster_to_hexwkb
 (rt_wkb.c:697 @ 41ce7c)
 }}}

 The lines 695 and 697 are these:
 {{{
 695-  while (wkbsize--) {
 696-    uint8_t v = *iptr++;
 697:    *optr++ = hexchar[v>>4];
 698:    *optr++ = hexchar[v & 0x0F];
 }}}

 It's interesting that v>>4 takes much more time than v & 0x0F. I wonder if
 it would make sense to make a 255 items table to speed it up further.

 As for flushes, I think you can control stdout buffering strategy.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2798#comment:17>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.