Re: rar
Vladislav Skraschuk wrote: On Monday 27 January 2003 13:33, Eugeny Nemo wrote: Здравствуйте, Andrew. Вы писали 27 января 2003 г., 16:23:55: A> Если у кого-нибудь был опыт работы с этим архиватором - поделитесь A> плиз впечатлениями. а какие могут быть впечатления? стабильно работает. A> А он сильно при этом CPU жрет? как обычно - 100%. покажите мне архиватор, который самостоятельно будет кушать меньше в процессе работы. =) A> И как с уровнем компрессии у него? m<0..5> Set compression level (0-store...3-default...5-maximal) мы жмём на m1, лишь бы чуть-чуть упаковать. всё равно эти архивы через неделю убиваются. руки дойдут - откажусь от rar'а. ибо - не open source. gzip или bzip2 не менее хорошие архиваторы. не менее то не меннее но вот есть файлик размером около 3Gb (Data.fs от Zope) так вот этот файлик ужимается раром с m5 до 250Mb, а bzip2 его ужимает в лучшем случае до 800Mb вот я и думаю то ли я bzip2 пользоваться не умею, то ли рар настолько сильнее сжимает ??? 1. Попробуйте разархивировать этот файл интересно получится ли 3G? Шутка :-) 2. На сколько мне известно Rar некоррктно архивирует файлы больше 4G. 3. В среднем Rar сжимает хуже чем bzip2 (покрайней мере тексты), но если вам повезло с вашим файлом и моделью сжатия выбранной в Rar - то можно этим пользоваться, но это скорее исключение чем правило.
Меня интересует де йствительно ли скольк о памяти ест mozilla?
Привет, Меня интересует сколько памяти ест mozilla? top показывает: 23043 oloniche 14 0 34972 33M 17420 S15.5 13.4 2:17 mozilla-bin 23049 oloniche 9 0 34972 33M 17420 S 0.0 13.4 0:00 mozilla-bin 23050 oloniche 9 0 34972 33M 17420 S 0.0 13.4 0:00 mozilla-bin 23051 oloniche 9 0 34972 33M 17420 S 0.0 13.4 0:00 mozilla-bin 23053 oloniche 9 0 34972 33M 17420 S 0.0 13.4 0:01 mozilla-bin 24321 oloniche 9 0 34972 33M 17420 S 0.0 13.4 0:00 mozilla-bin Значит ли это, что mozilla ест 33*6 или же просто 33 (т.к. используются одни и теже физические страницы). Заранее благодарен, Сергей
gprof нагло врет ?!
Привет все! Я тут оптимизировал свою программу: получил выход gprof, переписал две верхних функции и снова получил выход. Проблема в том, что они как занимали почти 5% по времени так и занимают. Хотя после оптимизации функция synt::SyntTokensSpliter::Clear() _состоит_в_обнулении_3-х_счетчиков_ и в принципе не может занимать 2.03% по времени от 441 секунды, т.е. почти 9 секунд. Правда общее время работы сократилось с 457.57 до 441.09 сек., но почему эти функции наверху? В чем может быть проблема? С уважением, Сергей P.S. До оптимизации gprof показывал: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 2.36 10.8010.8037194 0.29 0.30 synt::SyntTokensSpliter::ReTokenize() 2.12 20.50 9.7037195 0.26 0.26 synt::SyntTokensSpliter::Clear() ... После оптимизации стал показывать: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 2.36 10.4110.4137194 0.28 0.29 synt::SyntTokensSpliter::ReTokenize() 2.03 19.36 8.9537195 0.24 0.24 synt::SyntTokensSpliter::Clear() ...
как можно заморози ть просесс?
Привет Все! Существует ли какой-нибудь софт который позволяет остановить процесс и сбросить содержимое его памяти и регистров на диск. А потом (возможно после перезагрузки) - вновь создать этот процесс и запустить его? Просто на моей машине крутятся процессы по нескольку дней, и забарахлил кулер. Спасибо, Сергей
как определить пик овое количество памят и используемое програ ммой автоматически
Привет Все! Есть ли утилита, которая позволяет определить пиковое количество памяти используемое программой автоматически (т.е. также как time определяет время работы)? Если кто делал - подскажите каким образом ее лучше сделать? С уважением, Сергей
Re: как определить пи ковое количество памя ти используемое прогр аммой автоматически
Dmitry Astapov wrote: Evening, Sergei. Sergei Olonichev <[EMAIL PROTECTED]> 09:59 4/9/2003 wrote: SO> Привет Все! Есть ли утилита, которая позволяет определить пиковое SO> количество памяти используемое программой автоматически (т.е. также SO> как time определяет время работы)? Что значит "используемое автоматически"? Какие еще, по-твоему, есть виды использования? "Определять автоматически", а не "используемое автоматически" Можно еще посмотреть в top - это не подходит т.к. глазами я смотреть не хочу. Что есть пиковое кол-во? RSS? С учетом шареных библиотек или без? Всю выделенную память с учетом библиотек. Тебе зачем вообще это надо? Для автоматического тестирования своих программ.
Re: как определить пи ковое количество памя ти используемое прогр аммой автоматически
Всем большое спасибо.
Mikolaj Golub wrote:
Sergei Olonichev <[EMAIL PROTECTED]> writes:
Dmitry Astapov wrote:
...
Что-то типа того?
cat /proc/191/status | grep Vm | awk '{mem += $2} END{print mem " kB"}'
18844 kB
Это то что нужно!
Сергей
mmap на больших файла х ?
Привет Всем! Вот какой вопрос: У меня есть файл размером больше 4G. И есть приложение которое иногда читает этот файл по разным смещениям - как правило не более 50k. Причем одни смещения используются значительно чаще чем другие (а большинство возможных смещений не используется вообще). Мне бы хотелось максимально ускорить этот процесс чтения. Очевидно что использовать mmap на весь файл не получится. Есть ли смысл использовать mmap (c точки зрения производительности) перед непосредственным чтением определенного куска (те на ~50k) или нет? Заранее Большое Спасибо! Сергей
Re: mmap на больших файл ах ?
Aleksey Cheusov wrote: Sergei Olonichev <[EMAIL PROTECTED]> writes: Привет Всем! Вот какой вопрос: У меня есть файл размером больше 4G. И есть приложение которое иногда читает этот файл по разным смещениям - как правило не более 50k. Причем одни смещения используются значительно чаще чем другие (а большинство возможных смещений не используется вообще). Мне бы хотелось максимально ускорить этот процесс чтения. Очевидно что использовать mmap на весь файл не получится. Это почему это? потомучто указатель как был 32 bit так и остался как __off_t не определяй void * ptr = mmap (...); Тут у меня мысль появилась вот какая - я в этом файле все данные пересортирую таким образом чтобы те блоки куда обращенее происходит чаще всего находились вначале файла - друг за другом. И отображать в память буду только первые N - блоков - так чтобы размер отбражения не превосходил какою-то константу. Работа ускорится - плохо только что будет смесь из fred и *ptr 0,~>echo '#include ' | cpp -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURC> typedef long int __off_t; typedef __quad_t __loff_t; typedef __loff_t __off64_t; typedef __off64_t off_t; 0 0 0,~> Есть ли смысл использовать mmap (c точки зрения производительности) перед непосредственным чтением определенного куска (те на ~50k) или нет? Не перед, а вместо.
Re: mmap на больших файл ах ?
Eugene Onischenko wrote: Sergei Olonichev wrote: Aleksey Cheusov wrote: Sergei Olonichev <[EMAIL PROTECTED]> writes: Привет Всем! Вот какой вопрос: У меня есть файл размером больше 4G. И есть приложение которое иногда читает этот файл по разным смещениям - как правило не более 50k. Причем одни смещения используются значительно чаще чем другие (а большинство возможных смещений не используется вообще). Мне бы хотелось максимально ускорить этот процесс чтения. Очевидно что использовать mmap на весь файл не получится. Это почему это? потомучто указатель как был 32 bit так и остался как __off_t не определяй void * ptr = mmap (...); А зачем вам больше? 32 бита вполне хватит для Ваших 50k. Так в этом то и вопрос. Просто вызывать mmap на каждый блок (условно 50k) - это, здается мне, ни чем не лучше чем вызывать fread (с точки зрения скорости), а может еще и хуже. Если воспользоватся mmap64 (там offset 64 бита), соответственно передаем в последний параметр число 4 294 967 297ю Указатель который вернёт mmap64 (ptr) указывает на 4 294 967 297 байт в файле, а (char*)ptr+5 указывает на 4294967297+5 байт в вашем файле. это тоже самое что предлагал Cheusov Тут у меня мысль появилась вот какая - я в этом файле все данные пересортирую таким образом чтобы те блоки куда обращенее происходит чаще всего находились вначале файла - друг за другом. И отображать в память буду только первые N - блоков - так чтобы размер отбражения не превосходил какою-то константу. Работа ускорится - плохо только что будет смесь из fred и *ptr 0,~>echo '#include ' | cpp -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURC> typedef long int __off_t; typedef __quad_t __loff_t; typedef __loff_t __off64_t; typedef __off64_t off_t; 0 0 0,~> Есть ли смысл использовать mmap (c точки зрения производительности) перед непосредственным чтением определенного куска (те на ~50k) или нет? Не перед, а вместо.
Re: mmap на больших файл ах ?
2 Chuprina, Cheusov, Onischenko, Wagner, Orehov: Большое Спасибо за обсуждение.
