|
Subject: Fwd: Re[2]: speed of Binary serialization libraries Newsgroups: gmane.comp.lang.haskell.general Date: 2006-05-01 08:47:03 GMT (3 years, 9 weeks, 2 days, 18 hours and 57 minutes ago) continuing theme of fast serialization library, i should say that this library, Streams, also implements much faster general (text) I/O. below is it's results comparing to well-known Handles: ===8<==============Original message text=============== > Do you have a URL or darcs repository? http://freearc.narod.ru/Streams.tar.gz http://haskell.org/haskellwiki/Library/Streams - docs AltBinary is not yet documented, but al least you can do import Data.AltBinary import Data.Binary.ByteAligned and use the well-known NewBinary (GHC Binary) interface with openBinMem, get, put_ and all other functions. One more Streams-advertizing is the following table of text I/O speeds. It constructed, again, using 100 mb in each test. Strings I/O was tested using 15-char and 80-char lines (see conclusion at the end): Handle: vPutChar: 150.336 secs (user: 566.974 secs) vGetChar: 100.905 secs (user: 92.864 secs) vPutStrLn15: 34.310 secs (user: 31.165 secs) vGetLine15 : 18.397 secs (user: 16.914 secs) vPutStrLn80: 9.874 secs (user: 8.843 secs) vGetLine80 : 10.955 secs (user: 9.974 secs) vGetContents: 16.255 secs (user: -381.408 secs) Streams: File with locking: vPutChar: 48.900 secs (user: -384.632 secs) vGetChar: 48.029 secs (user: 44.304 secs) vPutStrLn15: 10.986 secs (user: 9.854 secs) vGetLine15 : 11.316 secs (user: 10.355 secs) vPutStrLn80: 5.618 secs (user: 4.987 secs) vGetLine80 : 8.672 secs (user: 8.032 secs) vGetContents: 14.571 secs (user: 13.379 secs) Streams: File: vPutChar: 3.065 secs (user: 1.222 secs) vGetChar: 1.232 secs (user: 1.082 secs) vPutStrLn15: 5.388 secs (user: 4.737 secs) vGetLine15 : 8.523 secs (user: 7.791 secs) vPutStrLn80: 4.687 secs (user: 4.076 secs) vGetLine80 : 7.822 secs (user: 7.200 secs) vGetContents: 14.831 secs (user: 13.640 secs) Streams: Memory-mapped file: vPutChar: 1.022 secs (user: 1.021 secs) vGetChar: 0.882 secs (user: 0.861 secs) vPutStrLn15: 4.667 secs (user: 4.246 secs) vGetLine15 : 7.451 secs (user: 6.920 secs) vPutStrLn80: 3.926 secs (user: 3.705 secs) vGetLine80 : 8.443 secs (user: 6.800 secs) Streams: File with UTF-8 encoding: vPutChar: 8.853 secs (user: 8.042 secs) vGetChar: 9.113 secs (user: 8.312 secs) vPutStrLn15: 10.005 secs (user: 8.933 secs) vGetLine15 : 13.770 secs (user: 12.518 secs) vPutStrLn80: 9.683 secs (user: 8.442 secs) vGetLine80 : 13.219 secs (user: 12.198 secs) vGetContents: 24.616 secs (user: 22.613 secs) Streams: MemBuf: vPutChar: 0.951 secs (user: 0.851 secs) vGetChar: 0.711 secs (user: 0.591 secs) vPutStrLn15: 4.446 secs (user: 4.166 secs) vGetLine15 : 7.130 secs (user: 6.599 secs) vPutStrLn80: 3.746 secs (user: 3.575 secs) vGetLine80 : 7.161 secs (user: 6.479 secs) vGetContents: 14.361 secs (user: 13.329 secs) as you can see, now, after all my optimizations, text I/O speeds are seriously limited by speed of lazy strings itself (getline/putline/getcontents are several times slower than getchar/putchar although it should be vice versa - much faster!). i foresee that Streams + Fast Packed Strings together will yield a breakthrough in GHC I/O speed, and this can be implemented even without waiting for GHC 6.6 ===8<===========End of original message text=========== -- Best regards, Bulat mailto:Bulat.Ziganshin <at> gmail.com |
|
|