Test code for this version (take 4) of the minimized LZO1X (from the liblzo v2) is complete. I don't see a significant slow-down comparing the complete liblzo2 to this minimized code on my system (Pentium M 1.73GHz, 1GB Ram, Kubuntu Feisty (stock Kubuntu kernel)). Rather, I see the opposite. This *might* have been caused by the dynamic linking (or similar) so rather than rely on simply doing "time xxx" I actually put checks around the calls to the compress/decompress functions themselves. ('Tiny LZO' is what I call Nitins extremely small implementation of lzo1x_[de]compress) Output of the provided "test" script: 10 run averages: 'Tiny LZO': Combined: 113.2 usec Compression: 77.4 usec Decompression: 35.8 usec 'liblzo2': Combined: 140.7 usec Compression: 94 usec Decompression: 46.7 usec (The "Combined" average is the average time taken for a compress+decompress) TODO: -Implement userspace version of likely/unlikely -Implement cpu_to_le16 so code functions on BE systems DRH
Attachment:
lzo1x-test.tar.bz2
Description: application/tbz
- Follow-Ups:
- Re: [RFC] LZO de/compression support - take 4
- From: "Nitin Gupta" <[email protected]>
- Re: [RFC] LZO de/compression support - take 4
- References:
- [RFC] LZO de/compression support - take 4
- From: "Nitin Gupta" <[email protected]>
- Re: [RFC] LZO de/compression support - take 4
- From: Daniel Hazelton <[email protected]>
- Re: [RFC] LZO de/compression support - take 4
- From: "Satyam Sharma" <[email protected]>
- [RFC] LZO de/compression support - take 4
- Prev by Date: BUG: at mm/slab.c:777 __find_general_cachep()
- Next by Date: Re: BUG: at mm/slab.c:777 __find_general_cachep()
- Previous by thread: Re: [RFC] LZO de/compression support - take 4
- Next by thread: Re: [RFC] LZO de/compression support - take 4
- Index(es):