Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Bulat Ziganshin <bulat.ziganshin <at> gmail.com>
Subject: Fwd: Re[2]: speed of Binary serialization libraries
Newsgroups: gmane.comp.lang.haskell.general
Date: Monday 1st May 2006 08:47:03 UTC (over 11 years 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@gmail.com
 
CD: 3ms