Gemstone laggy with new SageTV v9 install

[Fuzzy]

I'm just thinking java heap space, especially in the world of 64-bit JVM's, is much more plentiful than the image cache on the miniclient.

That said, I did go through and set the percent scaling in gemstone to approximately close to the final render size (guessed based on Dual view for banners, and Cover view for posters) and precached the fanart, just to get an idea of the size we're dealing with, and my 719 items in the GemstoneImages cache folder is only 17.5MB. It is highly likely a JVM side cache of appropriately sized images (with sufficiently low jpeg quality) would not make a huge dent in the JVM.

[stuckless]

Originally Posted by Fuzzy

I'm just thinking java heap space, especially in the world of 64-bit JVM's, is much more plentiful than the image cache on the miniclient.

That said, I did go through and set the percent scaling in gemstone to approximately close to the final render size (guessed based on Dual view for banners, and Cover view for posters) and precached the fanart, just to get an idea of the size we're dealing with, and my 719 items in the GemstoneImages cache folder is only 17.5MB. It is highly likely a JVM side cache of appropriately sized images (with sufficiently low jpeg quality) would not make a huge dent in the JVM.

The file system cache is not a good representation of how much much memory is used. For example, a single 2000x3000 jpg might only be 200K in size... but 22mb of memory is required to cache it in memory. That same image, if scaled to be max height of 1080 (assuming 1920x1080 display) consumes 3mb memory. (this sizes of how much memory is requires is HxWx(4 bytes per pixel) )

The SageTV server, out of box, will hold ~32mb of image cache, The miniclient uses 64mb, but I have my client to set to use 192mb and server the same.

The sagetv server has a property, ui/system_memory_2dimage_cache_scale (defaults to 2), that sets the cache size as a multiple of ~16m.

We might not agree on the caching and sizing specifics, but hopefully, you can see how IF you get a couple 20mb images showing up, it can have a disastrous effect on the UI performance, because it will, in effect, just dump everything in the cache to make room for it, and in my testing this can sometimes takes 6-7 seconds, but even a 500ms pause when you navigating up down in a list, it can be pretty apparent.

These numbers mean nothing in a stock sagetv setup, because 32mb is far more than what sagetv needs. It really only has an effect when you are showing backgrounds, posters, etc, since these image files consume so much more memory.

[Fuzzy]

Didn't realize that sage stores image data in an uncompressed raster format in it's serer side image cache. So that means it is sending the data uncompressed over the miniclient connection to be rendered as well? that seems wrong to me, when I would be certain the miniclient would have the capability to render from compressed image data.

[stuckless]

Originally Posted by Fuzzy

Didn't realize that sage stores image data in an uncompressed raster format in it's serer side image cache. So that means it is sending the data uncompressed over the miniclient connection to be rendered as well? that seems wrong to me, when I would be certain the miniclient would have the capability to render from compressed image data.

Keep in mind it doesn't matter how the image is stored in memory... the cache uses the H*W*4 to calculate whether or not the image can be added to the cache. This may be different than the "real" amount of memory required, and likely you cannot tell what the "real" value is (because there may be some additional overhead, etc), so logically, it uses a conservative calculation.

For every image that is loaded, it will check the size, determine if it can be added to the cache. If not, it will remove a "stale" item from the change, and re-check... this process continues until the image can be added to the cache. Keep in mind, in sagetv, every pieice of text of an "image" as well. So, it starts unloading images, it likely could be unloading text, and then later when you need to re-render that text, it has to go and fetch all those images again.

Images are sent across the wire as "compressed" images, but, images have to be uncompressed in order to work with them. The compression format is really only valid for storing the image... once you start doing things like compositing images, etc, they need to uncompressed.

[Taddeusz]

Originally Posted by stuckless

Keep in mind it doesn't matter how the image is stored in memory... the cache uses the H*W*4 to calculate whether or not the image can be added to the cache. This may be different than the "real" amount of memory required, and likely you cannot tell what the "real" value is (because there may be some additional overhead, etc), so logically, it uses a conservative calculation.

For every image that is loaded, it will check the size, determine if it can be added to the cache. If not, it will remove a "stale" item from the change, and re-check... this process continues until the image can be added to the cache. Keep in mind, in sagetv, every pieice of text of an "image" as well. So, it starts unloading images, it likely could be unloading text, and then later when you need to re-render that text, it has to go and fetch all those images again.

Images are sent across the wire as "compressed" images, but, images have to be uncompressed in order to work with them. The compression format is really only valid for storing the image... once you start doing things like compositing images, etc, they need to uncompressed.

That's horrible. This isn't just being conservative but wholly inaccurate. It sounds like this piece of code could use some tweaking. It shouldn't be that difficult to get the actual size of the data rather than calculating the estimated raw size of an uncompressed image.

[stuckless]

Originally Posted by Taddeusz

That's horrible. This isn't just being conservative but wholly inaccurate. It sounds like this piece of code could use some tweaking. It shouldn't be that difficult to get the actual size of the data rather than calculating the estimated raw size of an uncompressed image.

There might be some misinformation there... it's not inaccurate.. The H*W*4 is how many bytes it takes to uncompress the image (which it has to do)... What I'm saying is that the JVM implementation "may" do some other work so the real size (in memory) might be slightly smaller (or even slightly larger). I say it's "conservative" because not all images will have an alpha channel, and if not, then likely it could be *3 instead of *4, and as such the physical cache size might be smaller than the physical resident memory size... but that's not a bad thing.. it would be worse if cache size exceeded the physical memory size (since you'd get an OOM).

The purpose of the cache is really to set boundaries as to how many images are loaded. The H*W*4 is a very reasonable way to do this... since bigger images will take up more cache and smaller ones will take up less. Performance increases as you can keep more and more static images in memory. (which is why I increased my memory cache on the miniclient to 192mb)