Show must go on

Я просто оставлю это здесь.

Слева - время поиска слова «unix» в составленной из over 20000 текстовых файлов и корректно проиндексированной Sqlite3-базе.

Справа - время поиска того же слова через grep -lir в голой папке из тех же файлов.

Это на железе 2006 года.

Почему с флагом -i? Потому что скулайтовская версия тоже найдёт и uNix, и Unix.

Размер исходных файлов - ~ 470 мег, размер базы с индексами - ~ 982 мег. Но по скорости поиска на 30 гигах разрыв будет ещё в разы больше, ибо греп под такие объёмы тупо не оптимизирован.

Уже на этих размерах скулайт в >20 раз быстрее.

Эни квэшнс, мазафака?

Кому надо сам код каталогизатора, тяните здесь. Чистый баш и Sqlite3.

Сейчас как говорится на госуровне в России принуждают в торговле ставить такие железки называются фискальные регистраторы, которые печатают чеки и хранят историю покупок, вот вопрос твой к их изобретателям ещё хорошоб задать. Может быть от таких «изобретателей»-экономов ноги растут?

Какое отношение они имеют к системной кодировке? Конвертацией кодировки для них должна заниматься программа, которая с ними работает.

А я видел сайт в поддержку IE6.

О чём ты говоришь, он сидит на lynx-е в ядрёной консоли, топит за «экономию ресурсов» и при этом призывает грепать по 30 гигам текста вместо использования адекватных инструментов...

Это не он. Это отдельный, самобытный персонаж.

Да, заметил уже. Это страшная помесь луддизма микрободансера и наркомании эдди.

в нем кодовая страница вшита и это особенность устройства, то есть пользуйся той какая есть, никаких тебе там символов из unicode при печати

неадекваты, сэр

кто они??

Те, у кого КОИ-8 и «всеитакработаит!»

Неужели изучить эти инструменты труднее, чем кричать на каждом углу про ненужность юникода?

А ты как думаешь?

- 4 байта, вместо 1-го. Как я уже сказал, иногда это выливается в 65536 раз больший расход памяти.

Купите себе калькулятор. Это выливается ровно в 4 раза больший расход памяти.

Например, русская «й» может быть представлена одним символом (4 байта), а может быть проведена декомпозиция и нормализация (NFC, NKFD, NFKC) и тогда это будут два символа: и + ̆

И это разные символы/глифы, хоть и похожи по начертаниям. Если вы делаете нечеткий поиск, то вам нужно это учитывать, спору нет.

И вот, если потребности в многоязычном (более двух) представлении и особых символах нет, может оказаться проще и надёжнее использовать однобайтную кодировку.

Конвертация из юникода в однобайтовую, обработка, конвертация в юникод. Да, проще не придумать.

Конвертация из юникода в однобайтовую, обработка, конвертация в юникод

При локали KOI8-R остаётся только обработка.

Купите себе калькулятор. Это выливается ровно в 4 раза больший расход памяти.

Если удаётся применить поразрядную сортировку (radix sort), то не в 4 раза, а как раз в 256 в куб раз больше. Про 65536 я маленько напутал, в 16777216 раз больше. И медленнее в 4 раза.

Конвертация из юникода в однобайтовую, обработка, конвертация в юникод. Да, проще не придумать.

Конвертация по сложности вообще ничто по сравнению с обработкой и её при оценке сложности можно совсем не учитывать, особенно потому что для неё есть готовые средства вроде iconv

при нынешних мощностях экономия на размере символа сродни экономии на спичках

То-то Java Performance Team, поняв к 2016 году, что подавляющее большинство строк в ынтырпрайзе состоят из ASCII-символов, завели флажок, в зависимости от которого строки хранятся или по одному char (16 бит) на символ, как раньше, или по одному байту на символ.

Откуда там куб? Да, при наивном подходе бакетов будет 256^4 вместо 256, но едва ли кто в здравом уме станет их столько заводить, когда можно использовать хешмапу.

А на самом деле, и хешмапа не нужна, т.к. можно просто посортить их побайтно (только не считая нулевой байт терминатором строки, разумеется).

Ну начинается, там где можно обойтись без хэша, надо его заводить и следить за коллизиями. Не вопрос, всё это можно и если нужна обработка юникода, то и не обойтись без этого.

Но вопрос стоит так, что если не нужно, зачем лишние сложности? По опыту скажу, что хотя считается хорошим тоном делать универсальные вещи в расчёте на будущее масштабирование, на практике вот как-то убедился, что если таких требований не было с самого начала, оно себя редко, когда оправдывает. Лучше просто более гибкую и модульную архитектуру продумать, чем пытаться сразу делать с соображениями вроде, что вот сейчас обрабатываем массив русско-английских текстов, но вдруг когда-то понадобится ещё и французский и японский обработать. Вот когда понадобится, тогда и сделаем.

А на самом деле, и хешмапа не нужна, т.к. можно просто посортить их побайтно (только не считая нулевой байт терминатором строки, разумеется).

Если только посортировать, то может и можно побайтно в utf-8, но нужно не только сортировать, а много чего ещё. В общем, чего спорить, использование однобайтной кодировки в одной чисто практической задаче может быть заметно проще не нужного для неё юникода. Причём cp1251 хотя и слегка и не принципиально, но проще koi8-r.

Откуда там куб?
256^4 вместо 256,

А что это?

Ничего не понял. Можно ссылку на драму?

https://www.youtube.com/watch?v=hOF7sewi6pk#t=40m

В начале доклада ещё про сжатые ссылки в JVM, тоже довольно интересно, так что рекомендую посмотреть его целиком :)

Ах это милое представление мира в розовых очках Java :)

По ходу просмотра я так и не понял, почему докладчик так и не сказал «раньше у нас было как в UTF-16, а теперь, следуя новомодным тенденциям, сделаем как в UTF-8».

Учитывая java.lang.Character:

The Java platform uses the UTF-16 representation in char arrays and in the String and StringBuffer classes.

вообще выходит интересно: наконец то пришли к давнему выводу W3C.

Ну и в топике речь идет о Unicode vs. non-Unicode (однобайтный), а не UTF-8 vs UTF-16.

Там UTF-8 не предлагается, т.к. нужен доступ по индексу за O(1), а как раз однобайтная кодировка

При локали KOI8-R остаётся только обработка.

А исходный текст в koi кто вам подготовит? А отдавать вы обработанный текст тоже будете в koi?

Если удаётся применить поразрядную сортировку (radix sort),

А при чем тут поразрядная сортировка?

то не в 4 раза, а как раз в 256 в куб раз больше.

Это что за число вы возвели в куб, что у вас получилось 256?

Про 65536 я маленько напутал, в 16777216 раз больше. И медленнее в 4 раза.

Продолжайте жонглировать.

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

Ну так если у юзера и так локаль KOI8-R, то и тексты у него тоже в KOI8-R.

Одно из другого не следует.

Свои тексты и так в ней создаются, во многих случаях можно настроить так, что чужие тексты автоматически будут приходить в KOI8-R, а в остальных случаях можно собрать пучки текстов по кодировкам, и конвертнуть каждый из них по одной командой разом.

Чего только люди не придумаю, лишь бы не использовать utf-8.

Помню веселье в винХП, когда я не мог обьеденить немецкую и русскую локаль. Был выбор: или вся кирилица не работает, или кирилица работает норм, зато не работают немецкие умляуты и ß. После этого я придерживаюсь такого мнения:

Единственной кодировкой должна быть UTF-8 а использование других следует приравнять к разжиганию межнациональной розни и карать соответствующей статьёй УК.

http://ibash.org.ru/quote.php?id=9354

Конечно всякие встраиваимые системы и МК это исключения, там можно и однобайтные кодировки использовать =)

Абсолютно согласен.

А при чем тут поразрядная сортировка?

В расходе памяти, пропорциональном 2 в степени длина сортируемого элемента. Только не надо про хэши, в однобайтовых случаях, если не нужна полная сортировка можно и напрямую всё сделать.

В расходе памяти, пропорциональном 2 в степени длина сортируемого элемента.

Сортируемый элемент - это символ или строка? Зачем нужно постоянно сортировать элементы?

Только не надо про хэши, в однобайтовых случаях, если не нужна полная сортировка можно и напрямую всё сделать.

Вы придумали какой-то специфичный кейс для оправдания koi8. В реальной жизни он будет применяться?

Мне лично в utf-8 не нравится наполнение, а не сама идея многобайтовой кодировки, все эти бесполезные символы и абсолютно неуместные emoji, при всем этим нет элементарных it-шных символов и приходится прибегать к костылям в виде отдельных шрифтов, в итоге тот-же хабр выглядит как гдездо исламистов(а использовать шрифты сайтов отказываюсь, глаза дороже).

Экономить нужно только память и дисковое пространство. Т.е. те ресурсы, которых просто завались. Кому вообще далось это процессорное время???

Вы придумали какой-то специфичный кейс для оправдания koi8. В реальной жизни он будет применяться?

Я его применял в реальной жизни. Да, мог сделать посложнее и с юникодом, но обошёлся попроще cp1251.

Я его применял в реальной жизни. Да, мог сделать посложнее и с юникодом, но обошёлся попроще cp1251.

Это вся суть вендолюбов - прибить гвоздями к костылю.

Мне лично в utf-8 не нравится наполнение, а не сама идея многобайтовой кодировки, все эти бесполезные символы и абсолютно неуместные emoji,

Вы путаете теплое с мягким, utf8 - это способ хранения unicode символа.

Итого

Unicode-хейтеры: кто они?

Victims of a defective gene pool,
Soulless existence forever in pointless directions,
Out of tune with true evolution,
There are no answers, there is no solution!

© The Kovenant - Hollow Earth

Это вся суть вендолюбов - прибить гвоздями к костылю.

Мне уже смешно.

Нет, cp1251 был в линуксе, причём осознанно. Частично потому что и так большинство текста было в нём, частично из-за того что немного удобнее koi8-r.

Нет гвоздей и костылей, есть удачные и неудачные в текущий момент технические решения. Для универсальной библиотеки - это был бы костыль и проблемы с кодировками, для задачи обработать имеющуюся сейчас информацию - вполне нормально.

KISS - принцип.

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

Если обработать и выбросить, то нормально. Если результат обработки нужен для дальнейшего использования, то абсурдно.

Предполагаю, что большинство хейтеров — ниасиляторы средств работы с длинными символами в своём любимом языке программирования.

ну в общем то, работа с utf8 в C сложнее и медленнее, чем с кодировками фиксированной ширины. utf32 же имеет проблему в виде отсутствия обратной совместимости с ascii

вот кстати да. Полностью корректная работа с юникодом - та еще задачка

https://habrahabr.ru/post/243523/

Собираю вопросы к Эдди_ем. Пяшите что еще хотите спросить :)
Передам все лично.

4 месяца прошло...

C#

Нутыпонел.

А вы не обрекайте...

А то почувствуете на себе как
но он успел уж в вас воткнуть и там два раза провернуть свое оружье (мушка спилена, слава).

По каким причинам его ненавидят?

Вероятно всем должно хватить ASCII для всего, в том числе для общения текстом. Самый обыкновенный технофашизм на марше.

Коменты не читал.

C# лишь в качестве примера. В других языках не сильно большая разница. С ASCII строками вполне можно легко и быстро работать без привлечения сторонних библиотек. С строками в юникоде без сторонних библиотек, вроде ICU, тяжело.

USB - сам проприетарщина, и хороший пример того, что монополия - зло. Цена PID, одновременно с запрет передачи поддиапазонов VID сильно портит жизнь OpenHardware. Это не решение проблемы, а vendor lock.

Цена PID, одновременно с запрет передачи поддиапазонов VID

А кто мешает записать туда любое значение, не согласовывая PID?

Формальное несответствие стандарту и возможные конфликты с другими устройствами.