LZ4(or lzo) compression based caching

[GoogleCodeExporter]

I don't know how complex this would be to set up, but I know that ram is 
obviously faster than reading from the memory stick(even with the speedup), so 
I was wondering if it'd be possible to make the cached content be stored as 
compressed data in ram. If the lz4 compression algorithm was used(it's being 
talked about in the linux kernel so it obviously isn't tied to any one cpu 
arch), you'd be able to store _more_ data in the ISO cache.

Now then this whould be an enhancement and I don't know how complex the ISO 
cache code is nor how complex such a feature would be since it'd require some 
additional work in compression/decompression but it would allow more stuff to 
be stored in that _tiny_ 23MB of space that is available. 

I know that most of the team's moved onto the vita or well they seem to have 
and this is just a I can't think of the word for it, but basically bug fixes 
only state(I think?) but if it isn't this would be a great feature to have 
since it'd increase the amount of stuff that could be cached by a lot.

Finally if this is too complex, or I'm a crazy person just close this ticket, I 
just thought I'd ask on here to see if it was possible/doable since it'd be 
nice to see.

P.S. LZ4 is ~2x as fast as lzo, and compressed size is generally ~5% larger but 
still it usually compresses to ~75-80% of the original size in the worst cases 
that I've seen out there(thus far).

Original issue reported on code.google.com by 133794...@gmail.com on 21 Mar 2013 at 6:14

[GoogleCodeExporter]

OK, seems I couldn't change the priority to low, and the "type" to enhancement 
so sorry for that. Like I said, it's a 'wishlist' kinda feature. That and an 
ISO driver that supports it are also wishlist features.

Original comment by 133794...@gmail.com on 21 Mar 2013 at 6:15

[GoogleCodeExporter]

Using an uncompressed .iso on your original MS with read rates of 15-30Mb/s is 
more than enough and doesn't require .iso cache at all to load everything in 
full possible speed. Cache is mainly used for compressed .cso and/or UMD (since 
UMD has much lower read speeds than MS). Adding another 
compressing/uncompressing process will add additional load for the PSP's CPU 
which might actually result in longer loading times.

Original comment by piotrekhenry on 22 Mar 2013 at 12:41

[GoogleCodeExporter]

Ah OK, well then I should just enable "high memory layout" then since the iso 
cache isn't even being used then? Also my ms I'm using atm is a memory stick,my 
adapter broke so I'm stuck with a _small_ 4gb one. It's got ~8MB/s read, the 
other one is ~10-15MB/s avg. And I know that's still ~10x faster than the UMD. 
I only got class 4 cards for it since let's be honest here _anything_ would've 
been faster than the UMD(the sole reason I even got procfw in the first place). 

but anyway yeah, if someone could just destroy this bug then it seems rather 
useless. I would still love to see the lz4/lzo patch somehow make it into 
procfw since I imagine it'd yield much better results than the current gzip 
based implementation.

Finally, I love that this project is as user friendly as it is, it was nice to 
see how everything was kinda self explanatory. the only thing I'm still wishing 
for is that patch to make it upstream, then I'll have to edit my CISO script I 
got to use lzo instead of deflate. So that way I can have compressed ISOs 
without that much overhead since well you've said it too the overhead seems to 
be quite a lot.

Original comment by 133794...@gmail.com on 22 Mar 2013 at 4:27

[GoogleCodeExporter]

The ISO caching allows fast access to previously used data without requiring 
much CPU time.
If we apply a compression on it, then each access would take a longer time and 
in addition adding data to the cache pipeline would be insanely slower and very 
CPU extensive.

While it would allow to store more data in the cache, the performances would be 
greatly lowered.

Feel free to implement it yourself to see if it does improve the performances, 
but it's likely it won't.

Original comment by devnonam...@gmail.com on 26 Aug 2013 at 9:46

• Changed state: WontFix
• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

Well yeah, I have realized that awhile ago, I've since moved my efforts into 
the changing of the compressed ISO driver to add support for lz4 as it'd 
definitely be of a much greater use.

Original comment by 133794...@gmail.com on 26 Aug 2013 at 2:47