performance tradeoffs

[j.hudecek at nki.nl]

> -----Original Message-----
> From: Benjamin Gilbert via openslide-users
> Sent: donderdag 15 december 2016 6:09
> To: openslide-users at lists.andrew.cmu.edu
> Subject: Re: performance tradeoffs
> 
> On Thu, Dec 08, 2016 at 01:12:56PM +0000, j.hudecek--- via openslide-users wrote:
> > I'm struggling with performance of OpenSlide to dynamically generate 
> > tiles for OpenSeadragon from images stored on a network drive.
> > 
> > Some tiles load in 50ms (usually the bottom level) but some take 2s or 
> > more - some images only have two layers so OpenSlide needs to read 
> > huge pieces of image (I've seen up to 16 times the size of resulting 
> > tile) to satisfy my deepzoom request.
> 
> Slides without low-resolution levels just aren't going to perform well when zoomed out.  The best you can do is precompute, cache, or prevent generation of those DZ levels.  OpenSeadragon can also be configured not to load the smallest DZ levels, which can reduce the impact of the initial "progressive enhancement" phase when loading a DZ image.

I've changed the call to get best level to prevent unnecessary resizing so it's not resizing 16 times when there usable layers:
var best_level = openslide_get_best_level_for_downsample(handle, downsample * 1.01); 
I'm still considering whether to skip loading of lower levels which need to be resized (i.e. level 16 in an image with 17 dz levels). Is there an easy way to do it in OpenSeaDragon without writing a custom TileSource?

> 
> > I attached procmon when reading the files and it seems that OpenSlide 
> > is making a lot of overlapping 4K reads unaligned to 4K.  Is it 
> > possible to force it to use a larger buffer for example?
> 
> With most slide formats, OpenSlide should be reading an entire slide tile at once, and I wouldn't expect overlapping reads.  What format are you using? 
> Could you post an I/O trace?

Time of Day;us;Details
12:26:48;6020281;Offset: 891.535.334, Length: 4.096, Priority: Normal
12:26:48;6197893;Offset: 891.535.540, Length: 4.096, Priority: Normal
12:26:48;6430649;Offset: 893.866.632, Length: 4.096, Priority: Normal
12:26:48;6631329;Offset: 893.866.814, Length: 4.096, Priority: Normal
12:26:48;6810251;Offset: 1.000.266.708, Length: 4.096, Priority: Normal
12:26:48;6977374;Offset: 1.000.266.710, Length: 4.096, Priority: Normal
12:26:48;7137262;Offset: 1.000.266.902, Length: 4.096, Priority: Normal
12:26:48;7351524;Offset: 1.000.266.906, Length: 4.096, Priority: Normal
12:26:48;7610001;Offset: 1.000.266.912, Length: 4.096, Priority: Normal
12:26:48;7855050;Offset: 1.000.267.016, Length: 12.288, Priority: Normal
12:26:48;7855843;Offset: 1.000.279.304, Length: 4.096
12:26:48;8102624;Offset: 1.000.283.216, Length: 12.288, Priority: Normal
12:26:48;8103398;Offset: 1.000.295.504, Length: 4.096
12:26:48;8270482;Offset: 1.000.299.416, Length: 4.096, Priority: Normal
12:26:48;8422064;Offset: 917.853.486, Length: 28.672, Priority: Normal
12:26:48;8422893;Offset: 917.882.158, Length: 4.096
12:26:48;8603189;Offset: 917.808.545, Length: 40.960, Priority: Normal
12:26:48;8604164;Offset: 917.849.505, Length: 4.096
12:26:48;8847467;Offset: 917.793.886, Length: 12.288, Priority: Normal
12:26:48;8848197;Offset: 917.806.174, Length: 4.096
12:26:48;9097860;Offset: 917.785.442, Length: 8.192, Priority: Normal
12:26:48;9098495;Offset: 917.793.634, Length: 4.096
12:26:49;170997;Offset: 917.776.903, Length: 8.192, Priority: Normal
12:26:49;171810;Offset: 917.785.095, Length: 4.096
12:26:49;711438;Offset: 917.756.650, Length: 16.384, Priority: Normal
12:26:49;712227;Offset: 917.773.034, Length: 4.096

this is an SVS file (85655x42392, 1.015.595.857B) with these levels:
openslide.level[0].downsample: 1
openslide.level[0].height: 42392
openslide.level[0].tile-height: 240
openslide.level[0].tile-width: 240
openslide.level[0].width: 85655
openslide.level[1].downsample: 4.0000700509036573
openslide.level[1].height: 10598
openslide.level[1].tile-height: 240
openslide.level[1].tile-width: 240
openslide.level[1].width: 21413
openslide.level[2].downsample: 16.002163842743812
openslide.level[2].height: 2649
openslide.level[2].tile-height: 240
openslide.level[2].tile-width: 240
openslide.level[2].width: 5353
openslide.level[3].downsample: 32.013360903002635
openslide.level[3].height: 1324
openslide.level[3].tile-height: 240
openslide.level[3].tile-width: 240
openslide.level[3].width: 2676

> > It also seems that tile size (for the Deepzoom) makes a lot of difference. 
> > Would it make sense to tweak it based on the underlying image and its 
> > tile size (if it's a pyramidal image)?
> 
> The DZ tile size should primarily affect the number of round trips from OpenSeadragon to your server.  I wouldn't expect major gains from tuning it based on the slide's tile size.

I've tried changing the tile size for this slide (with internal tile size 240) from 512 to 480 and it seems the DZ requests ran consistently 10% faster (for 6% less data). So it's probably not worth it.

Jan