Performance of wcps query involving multiple overlays

[Dirk Daems]

Since I upgraded to Rasdaman version 8.4, WCPS queries involving multiple overlay functions (see example below) take much longer to return. Looking at the Petascope log file, it appears that the translation of WCPS to RASQL is taking much longer. I am aware of the fact that since version 8.4 the overlay operator is implemented the correct way (ticket 219) so I had to swap the order of the overlays. The translation of WCPS to RASQL on v8.3 took less than a second, while on v8.4 it now takes 90(!) seconds.

for c in (Biopar_Tile_LAI)
return encode(
  (char)(({
    red:   ((char)((c < 20) * 200));
    green: ((char)((c < 20) * 10));
    blue:  ((char)((c < 20) * 10))
  }
overlay
  (char){
    red:   ((char)((c >= 20 and c < 25) * 255));
    green: ((char)((c >= 20 and c < 25) * 165));
    blue:  ((char)((c >= 20 and c < 25) * 0))
  }
overlay
  (char){
    red:   ((char)((c >= 25 and c < 30) * 255));
    green: ((char)((c >= 25 and c < 30) * 215));
    blue:  ((char)((c >= 25 and c < 30) * 0))
  }
overlay
  (char){
    red:   ((char)((c >= 30 and c < 35) * 255));
    green: ((char)((c >= 30 and c < 35) * 255));
    blue:  ((char)((c >= 30 and c < 35) * 0))
  }
overlay
  (char){
    red:   ((char)((c >= 35 and c < 40) * 173));
    green: ((char)((c >= 35 and c < 40) * 255));
    blue:  ((char)((c >= 35 and c < 40) * 47))
  }
overlay
  (char){
    red:   ((char)((c >= 40 and c < 45) * 20));
    green: ((char)((c >= 40 and c < 45) * 255));
    blue:  ((char)((c >= 40 and c < 45) * 20))
  }
overlay
  (char){
    red:   ((char)((c >= 45 and c < 50) * 10));
    green: ((char)((c >= 45 and c < 50) * 200));
    blue:  ((char)((c >= 45 and c < 50) * 10))
  }
overlay
  (char){
    red:   ((char)((c >= 50 and c < 55) * 0));
    green: ((char)((c >= 50 and c < 55) * 136));
    blue:  ((char)((c >= 50 and c < 55) * 0))
  }
overlay
  (char){
    red:   ((char)((c >= 55 and c < 253) * 0));
    green: ((char)((c >= 55 and c < 253) * 0));
    blue:  ((char)((c >= 55 and c < 253) * 255))
  }
overlay
  (char){
    red:   ((char)((c = 253) * 0));
    green: ((char)((c = 253) * 0));
    blue:  ((char)((c = 253) * 250))
  }
overlay
  (char){
    red:   ((char)((c = 254) * 255));
    green: ((char)((c = 254) * 235));
    blue:  ((char)((c = 254) * 190))
  }
overlay
  (char){
    red:   ((char)(c = 255) * 80);
    green: ((char)(c = 255) * 80);
    blue:  ((char)(c = 255) * 80)
  }
 
)[x(-10:-7),y(37:40)])[t(458)]
,
"png")

A also attached the Rasdaman and Petascope log files that were generated when executing the query.

[Dimitar Misev]

Can you completely disable petascope's output, just to confirm that the issue is too much logging. In general for production use the logging should be at INFO, but as I can see there's some ERROR logs which are wrongly marked as ERROR.

[Dirk Daems]

I switched the log level to OFF but the query still takes 5 times longer when it is executed on v8.4 (log level OFF) compared to v8.3 (log level TRACE). So reducing the logging output helps, but there seems to be another cause as well.

[Dimitar Misev]

Patch submitted.

[Dimitar Misev]

Can you please try with the latest rasdaman, the patch was applied.

[Dirk Daems]

Tried with the latest version but the problem remains.

[Dimitar Misev]

Can you attach the new petascope log (DEBUG)? Thanks.

[Dirk Daems]

New Petascope logging output

[Dimitar Misev]

New patch submitted

[Dimitar Misev]

Fixed by changeset:199661c, please reopen if the bug still persists.