https://www.opennet.ru/openforum/vsluhforumID3/57870.html Сравнение (http://denisy.dyndns.org/lzo_vs_lzjb/) методов сжатия LZO и LZJB в реализации файловой системы ZFS для FreeBSD, чтобы подтвердить утверждение, что LZO работает быстрее и сжимает лучше, чем стандартный в ZFS метод LZJB.<br><br>URL: http://denisy.dyndns.org/lzo_vs_lzjb/<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=23033<br> https://www.opennet.ru/openforum/vsluhforumID3/57870.html#6 Sun, 16 Aug 2009 13:12:43 GMT iWorks 08 Numbers<br> https://www.opennet.ru/openforum/vsluhforumID3/57870.html#5 Sat, 15 Aug 2009 19:47:47 GMT не особо красиво, учитывая перспективу, освещение и получаемую тень.<br> https://www.opennet.ru/openforum/vsluhforumID3/57870.html#4 Sat, 15 Aug 2009 11:29:01 GMT Потому что юзеры повесятся на сетевом шнуре, дожидаясь окончания записи файла на несколько гигз...<br> https://www.opennet.ru/openforum/vsluhforumID3/57870.html#3 Sat, 15 Aug 2009 06:15:12 GMT подскажите, чем рисуют такие красивые графики?<br> https://www.opennet.ru/openforum/vsluhforumID3/57870.html#2 Fri, 14 Aug 2009 23:01:05 GMT Железка 2.4 Ггц Core 2<br>3 Гб памяти.<br><br>LZO оказался быстрее на декопрессии бинарных (сжимаемых) и текстовых (сжимаемых) тестовых пакетов (357-400Мб/c), с лучшим сжатием. Но скорость сжатия оказалась немного меньше (129-140 - lzo, 147-166 Mb/s для lzjb), а в случаем несжимаемого содержимого пямиком из /dev/urandom регистрация самого факта практической несжимаемости данных занимала гораздо больше (в четыре раза) времени с алгоритмом lzo.<br><br>Тестовые пакеты не слишком велики - 482 Мб исходников в первом пакете, 801MB средненамешанных объектных данных с тестовыми, и 200Мб кусок случайных данных.<br> https://www.opennet.ru/openforum/vsluhforumID3/57870.html#1 Fri, 14 Aug 2009 19:20:52 GMT А почему бы не взять lzma?<br>