[21 век][технологии] iconv

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

f3ex (10.04.2010 2:44:11)

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

NekoExMachina (10.04.2010 2:45:00)

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

NekoExMachina (10.04.2010 2:45:23)

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

melkor217 (10.04.2010 2:45:38)

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

melkor217 (10.04.2010 2:49:52)

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

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

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

xintrea (10.04.2010 2:51:41)

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

f3ex (10.04.2010 2:55:17)

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

melkor217 (10.04.2010 2:56:31)

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

melkor217 (10.04.2010 2:57:26)

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

f3ex (10.04.2010 2:58:09)

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

melkor217 (10.04.2010 3:03:34)

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

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:~$

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

melkor217 (10.04.2010 3:11:01)

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

melkor217 (10.04.2010 3:18:44)

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

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

f3ex (10.04.2010 3:22:57)

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

f3ex (10.04.2010 3:25:05)

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

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
    Л.Н. ТОЛСТОЙ
    ВОЙНА И МИР

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

f3ex (10.04.2010 4:30:27)

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

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 и смело тянут файлы в оперативку.

melkor217 (10.04.2010 4:30:41)

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

melkor217 (10.04.2010 4:33:27)

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

f3ex (10.04.2010 4:37:16)

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

melkor217 (10.04.2010 4:40:32)

>Written by Bruno Haible.

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

iZEN (10.04.2010 8:52:28)

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

NekoExMachina (10.04.2010 11:32:57)

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

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

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

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

Quasar (10.04.2010 12:27:07)

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

NekoExMachina (10.04.2010 12:42:56)

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

spunky (10.04.2010 15:15:32)

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

Скачиваю

melkor217 (10.04.2010 22:36:39)

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

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

melkor217 (10.04.2010 22:40:11)

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

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

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

tx (10.04.2010 23:29:15)

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

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

thesame (10.04.2010 23:45:18)

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

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

melkor217 (10.04.2010 23:48:32)