From: Francesc A. <fa...@py...> - 2004-06-23 12:28:03
|
A Dimarts 22 Juny 2004 13:27, Francesc Alted va escriure: > An small update: I re-made this C benchmark, but using only the zlib > compressor (i.e. whitout shuffling) and setting all data to zeros, and I've > obtained 33 MB/s. Without compression, that figure may perfectly grow up to > 40 MB/s (whenever the hard disk would support this throughput, of course). More updates ;). This morning I remembered that Table objects has a much more efficient interface for writing than EArrays (just because I've spend more time on optimizing Tables than anything else), and besides, I've recently reworked the algorithm to compute buffer sizes for Tables, in order to make them still faster. And the good news is that all of this largely address to this problem :) So, if you use the lastest CVS and use a Table instead of an EArray, this small script would be far more efficient than the equivalent using EArrays: ***************************************************** import tables import numarray as na class Test(tables.IsDescription): var1 = tables.UInt8Col(shape=(640,480)) nframes = 200 filename = "data.nobackup/test2.h5" fileh = tables.openFile(filename, mode="w", title="Raw camera stream") root = fileh.root filter_args = dict( complevel = 1, complib = 'lzo', shuffle=0) hdftable = fileh.createTable(root,'images', Test, "Unsigned byte table", tables.Filters(**filter_args), expectedrows=nframes) frame = na.zeros(type="UInt8", shape=(640,480)) for i in range(nframes): hdftable.row["var1"] = frame hdftable.row.append() fileh.close() ***************************************************** With it, I was able to save frames at a speed of 46.2 MB/s without compression (this script generates a 60 MB file, so that it fits well on my laptop cache). Using ZLIB, I've got 36.4 MB/s, with LZO compression 54.5 MB/s and with UCL it drops down to 8.0 MB/s. I was curious about how much memory would take a long run, and I made a test with 20000 frames for a total dataset size of 6 GB. I've used LZO compressor in order to keep the file size small. With that, the run took 1m23s, for a total throughput of more than 70 MB/s. And the process took 16 MB of memory during the run, which is quite reasonable. However, there seems to be a "small" memory leak that develops at a rate of 3 KB/frame. Whether this is acceptable or not is up to you. Cheers, -- Francesc Alted |