Хм, переконвертил гиговый файлик (из unrandom), помяти потреблял (по htop'у) не более 25% (из гига физической памяти), CPU 10-15%

Гм, я видимо не то читал.

В мейлинг-листе каком-то было, что urandom и random таки отличаются. ну да ок.

А теперь `iconv --version` сюда )

Свап точно выключен?

> А как-то не предполагается, что бывают текстовые файлы гигабайтных размеров. Я вообще не представляю, что в таком файле может быть?

Когда в госконторе экспортирут извещения на весь город для печати на матричном рулонном принтере, файлы и по 10 гигов бывают.

С редактированием таких файлов походу справляется только мультиедит, ибо рассматривает файл как поток, выделяя в нем только обрабатываемый кусок. Но как переконвертить кодировку через мультиедит, я не представляю.

чет не обратил на него внимание в прошлый раз. Вырубил своп. всего лишь 10-12% памяти %)

Странно как-то. Есть серьёзные подозрения, что 25% твоей «физической памяти» это и есть тот самый файл )

У тебя убунту, судя по всему. Я на ней тоже пробовал - тоже валится.

давай для чистоты эксперимента увеличим размер файла в 2 раза, до 2-х Гб. Знать бы как точно замерить максимально потребление памяти приложением...

Уже генерирую тест-файлы. Смотреть буду «на глаз» в top.

ага, не тут-то было.

dan@dan-desktop:~$ iconv -f cp1251 -t utf8 xaa -o xab
iconv: невозможно открыть входной файл «xaa»: Значение слишком велико для такого типа данных
dan@dan-desktop:~$ ls -lh xaa
-rw-r--r-- 1 dan dan 2,0G Апр 10 03:07 xaa
dan@dan-desktop:~$

а при чтении из потока всё так же отжирает всю память и вываливается.

Видимо, зря я в своё время смеялся над пунктом «Large File Support» целях релиза squeeze )

да, кубунту стоит. Но тем не менее прошло =)

f3ex@f3ex:/tmp$ dd if=/dev/urandom of=/tmp/qwe.txt count=2000 bs=1M
2000+0 записей считано
2000+0 записей написано
скопировано 2097152000 байт (2,1 GB), 444,942 c, 4,7 MB/c
f3ex@f3ex:/tmp$ sudo swapoff /dev/sda5
f3ex@f3ex:/tmp$ time iconv -f CP1251 -t UTF-8 -c qwe.txt > qwe.txt.utf8

real    4m22.273s
user    0m33.494s
sys     0m10.197s

f3ex@f3ex:/tmp$ ls -lh qwe.txt*
-rw-r--r-- 1 f3ex f3ex 2,0G 2010-04-10 03:16 qwe.txt
-rw-r--r-- 1 f3ex f3ex 3,1G 2010-04-10 03:21 qwe.txt.utf8

теже 10-12% потребления памяти, CPU порядке 20-30%

Обычный текстовик тоже прошел. Пару раз вывел «войну и мир» в файл, и прогнал его через иконв:

f3ex@f3ex:/tmp$ file qwe.txt*
qwe.txt:      Non-ISO extended-ASCII text, with CRLF line terminators
qwe.txt.utf8: UTF-8 Unicode text, with CRLF line terminators
f3ex@f3ex:/tmp$ ls -lh qwe.txt*
-rw-r--r-- 1 f3ex f3ex 1,9G 2010-04-10 04:20 qwe.txt
-rw-r--r-- 1 f3ex f3ex 3,3G 2010-04-10 04:26 qwe.txt.utf8
f3ex@f3ex:/tmp$ head -n2 qwe.txt.utf8
    Л.Н. ТОЛСТОЙ
    ВОЙНА И МИР

ну да, во всяком случае, чтобы понять что там действительно происходит - надо смотреть исходники, что сейчас правда лениво делать =) если будет инфа - напиши плиз.

А теперь самое интересное

dan@dan-desktop:~/qweqwe$ time iconv -f CP1251 -t UTF-8 xaa > xab
 
real	1m25.683s
user	0m23.437s
sys	0m3.884s




dan@dan-desktop:~$ time iconv -f CP1251 -t UTF-8 -c xab > testfile3 
iconv: невозможно открыть входной файл «xab»: Значение слишком велико для такого типа данных 
 
real   0m0.002s 
user   0m0.000s 
sys   0m0.000s





dan@dan-desktop:~/qweqwe$ ls -l xaa
-rw-r--r-- 1 dan dan 2147483647 Апр 10 04:20 xaa
-rw-r--r-- 1 dan dan 2147483648 Апр 10 03:07 xab

Гениально. Ограничили размер по INT_MAX и смело тянут файлы в оперативку.

Да, судя по мониторингу через htop, памяти оно ест 66% из 3Гб, тут трудно с чем-то спутать.

а почему у меня не ест столько? 66% от 3Гб, это и есть 2гб =((

Завтра более детально сравню с последней убунтой и стабильным дебианом. Вечером отпишусь о результатах.

>Written by Bruno Haible.

«Ничего не могу поделать, с каждым днем приходится все дальше и дальше уходить от бочки» (с) Шлемиль

И причем тут это, если в этой версии все нормально работает?

melkor217> Оказывается, оно перед тем, как начать конвертировать, загоняет весь файл в оперативку.

Если работать напрямую, через винчестер - будет особо медленно работать.

melkor217> Где я возьму столько памяти?

Где ты берёшь такие большые текстовые файлы?

базы данных, например, нэ? ._.

для обработки информации следует грамотно использовать соответствующее задаче оборудование и ПО.

Где ты берёшь такие большые текстовые файлы?

Скачиваю

Если работать напрямую, через винчестер - будет особо медленно работать.

Лучше медленно, да надёжно. Нас так даже в школе на информатике учили ._.

> Где я возьму столько памяти? НЕНАВИСТЬ!

У меня бОльшую ненависть вызывает обратная ситуация, когда прога за каждой новой строчкой обращается к диску. ОС со всякими кэшами это конечно значительно сглаживает, но сам подход...

Да и где ты берёшь текстовые файлы таких размеров?

>прога за каждой новой строчкой обращается к диску

а ты предлагаешь в каждой проге городить кеш с префетчем и шлюхами?

У меня бОльшую ненависть вызывает обратная ситуация, когда прога за каждой новой строчкой обращается к диску

Почти все утилиты юникса обучены работать с потоками и именно так и делают. Пока мало кто жаловался )