On Wednesday 03 June 2009 23:27:49 Matthew Toseland wrote: > I propose to solve bug #3171 by having two compression threads, one for > very small files (say up to 64K), and one for everything else. This relies > on the assumption that compressing something very small uses very little > memory. Is this a fair assumption? Do lzma or bzip2 allocate big tables up > front which depend on the size of the window and not on the size of the > file? Do we need to adapt the size of the window to the size of the file?
I second that. Currently, when large inserts are being compressed, Freetalk message insert stall until the compression of the large inserts is finished. They might stall for a very long time if you run very large inserts (few hundred MiB). This is bad. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090609/c77dcdc5/attachment.pgp>
