[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200705280418.07538.dhazelton@enter.net>
Date: Mon, 28 May 2007 04:18:07 -0400
From: Daniel Hazelton <dhazelton@...er.net>
To: "Satyam Sharma" <satyam.sharma@...il.com>
Cc: "Richard Purdie" <richard@...nedhand.com>,
"Nitin Gupta" <nitingupta910@...il.com>,
linux-kernel@...r.kernel.org, linux-mm-cc@...top.org,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Andrey Panin" <pazke@...pac.ru>, "Bret Towe" <magnade@...il.com>,
"Michael-Luke Jones" <mlj28@....ac.uk>
Subject: Re: [RFC] LZO de/compression support - take 4
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
Download attachment "lzo1x-test.tar.bz2" of type "application/x-tbz" (6279 bytes)
Powered by blists - more mailing lists