Вызов нового потака в руби нефига не емкая задача. Патамучта green threads.
Пусть у нас модный сервер с 64 ядрами.
Считать надо не процессы, а активные процессы (вы часто видете L/A == 64?). Выигрыш в производительности - если вам надо опрасить 10 серверов и на каждый запрос уходит 0.1 - 0.2 c то что будет лучше - держать 1 активный поток 1-2 секунды или 10 по 0.1 - 0.2? Сплошной FUD.
Простите, забыл что сложность кода уже давно не измеряют в ассемблерных инструкциях. Если потрудитесь скомпилировать и дизассемблировать, то увидете те самые "пару лишних тактов процессора" про которые я писал выше.
substr - это из пэхапэ который?
в Unix Си strcpy и strncpy бегут по source строке и проверяют каждый символ на 0x0. По сути тот же алгоритм что в strlen. Только в случае с utf-8 искать надо будет 0x0 или начало следующего символа (условие из if) минус 1 байт. По вашему это сложно?
Ну что, я пошел рисовать звездочку на крышке ноута? ,-)
Нормализация = последовательный просмотр всей строки = можно смело забыть про производительность.
1 - обратная совместимость
2 - 100тыс vs 65535 (0xFFFF)
Производительные Unicode-приложения в Web позволяет создавать horizontal scalability а не кодировка. Производительность - это правильные алгоритмы и кеширование, а не кодировка. Производительность - это выбор в пользу компилируемых языков, а не utf vs ucs. Производительность это грамотная архитекрура...
Ну тогда strlen для юникода - это вообще один большой вопрос. Банальный U-умляут может быть закодирован как минимум двумя разными способами, что в таком случае считать длинной? Так что "парсить" придется в любом случае...
Речь не шла о поиске N-ного символа в 10Гб текста. Будте внимательнее.
В отличии от ucs-2:
- utf-8 решает проблему перехода на Unicode (совместимость с ASCII)
- В utf-8 влезает весь unicode range (U+10FFFF), в то время как в ucs-2 только U+FFFF
- В utf-8 не возможно распространение ошибки более чем на 1 кодпоинт. (Если в ucs-2 первый байт потеряется, то обнаружить ошибку невозможно и все последующие последовательности будут декодированны неверно, в utf-8 сразу будет обнаружена ошибка).
А теперь встречный конкретный вопрос: какие же проблемы не может решить utf-8, но их решает ucs-2?
Мне нужны практические тесты, и практическое доказательство того, что "utf-8 — это ужасно". Давайте посмотрим как сильно изменятся алгоритмы strlen и substr если мы возмем utf-8.
strlen для utf-8 будет работать так же быстро, т.к. маркер конца строки такой же как и в c-string — 0x00.
substr будет немного медленнее т.к. надо будет вычислять количество единиц в первых 4 битах для определения длинны закодированого кодпоинта и двигать указатель на это значение. Ну да, пара дополнительных тактов процессора. Сложность "алгоритма получения символа по номеру" не меняется. Ну и если вы попробуете максимально быстро посчитать количество предложений/строк/слов/букв в 10Гб текста то упретесь в производительность носителя (hdd, сеть, память), а не производительность процессора. На объемах до 100кб разница будет не большой, и беспокоиться тут не о чем. Но, если вдруг, в вашей задаче необходимо много раз вычислять длинну слов/строк/предложений, то вариант с перекодированием в fixed-width, и/или хранением мета-информации, и/или precalculated values будет оптимальнее (в большинстве случаев в не зависимости от кодировки)...
Variable width удобнее передавать по сети, а fixed width удобнее обрабатывать. И если вы забиваете гвозди микроскопом - то это ваша проблема, а не микроскопа. Не надо использовать utf-8 там, где оптимальнее использовать другой вариант кодирования.
Мне кажется, что utf-8 решает гараздо больше проблем чем создает. И благодаря именно этой кодировке мы все медленно, но верно переходим на юникод. Поэтому ваше утверждение о том, что "utf-8 – это ужасно" – не совсем корректно.
Покажите тесты для strlen, substr, и тогда ваши "аргументы" станут Аргументами. Так же, вы могли бы предложить более оптимальный вариант кодировки. А на данный момент все ваши утверждения просто голословны и не несут под собой ни каких фактов.
"Минусы существенны — кодировка имеет нефиксированную длину символа, поэтому..."
Вроде по-русски написали, что внутреннее представление строк обычно не utf-8, а UCS в которой длинна символа фиксированна.
"...приходится проходить всю строку или нужно хранить метаинформацию..."
Избыточность при хранении длинны строки вместе со строкой не значительна. Посколько cstrings должны заканчиваться \0x0 символом, то разница в 1-3 байта на строку для хранения размера - не столь существенна.
UTF-8 ужасен? С тем же успехом, можно утверждать что данные по ethernet следует передавать азбукой морзе. А трафик дешевеет во многом благодоря именно новым методам кодирования информации.
Про мелкие ляпы типа "«использовать» (агрегация, ассоциация)" даже писать не хочется :)
Пусть у нас модный сервер с 64 ядрами.
Считать надо не процессы, а активные процессы (вы часто видете L/A == 64?). Выигрыш в производительности - если вам надо опрасить 10 серверов и на каждый запрос уходит 0.1 - 0.2 c то что будет лучше - держать 1 активный поток 1-2 секунды или 10 по 0.1 - 0.2? Сплошной FUD.
substr - это из пэхапэ который?
в Unix Си strcpy и strncpy бегут по source строке и проверяют каждый символ на 0x0. По сути тот же алгоритм что в strlen. Только в случае с utf-8 искать надо будет 0x0 или начало следующего символа (условие из if) минус 1 байт. По вашему это сложно?
Ну что, я пошел рисовать звездочку на крышке ноута? ,-)
http://insa.pp.ru/files/strlen_utf.c
Можете скомпилировать и посмотреть на сколько больше стал код по сравнению с стандартным strlen'ом.
Бенчмарки там всякие провести, алгоритмы поанализировать ,-)
1 - обратная совместимость
2 - 100тыс vs 65535 (0xFFFF)
Производительные Unicode-приложения в Web позволяет создавать horizontal scalability а не кодировка. Производительность - это правильные алгоритмы и кеширование, а не кодировка. Производительность - это выбор в пользу компилируемых языков, а не utf vs ucs. Производительность это грамотная архитекрура...
(похоже каждый при своем остался мнении ,-) )
Речь не шла о поиске N-ного символа в 10Гб текста. Будте внимательнее.
В отличии от ucs-2:
- utf-8 решает проблему перехода на Unicode (совместимость с ASCII)
- В utf-8 влезает весь unicode range (U+10FFFF), в то время как в ucs-2 только U+FFFF
- В utf-8 не возможно распространение ошибки более чем на 1 кодпоинт. (Если в ucs-2 первый байт потеряется, то обнаружить ошибку невозможно и все последующие последовательности будут декодированны неверно, в utf-8 сразу будет обнаружена ошибка).
А теперь встречный конкретный вопрос: какие же проблемы не может решить utf-8, но их решает ucs-2?
strlen для utf-8 будет работать так же быстро, т.к. маркер конца строки такой же как и в c-string — 0x00.
substr будет немного медленнее т.к. надо будет вычислять количество единиц в первых 4 битах для определения длинны закодированого кодпоинта и двигать указатель на это значение. Ну да, пара дополнительных тактов процессора. Сложность "алгоритма получения символа по номеру" не меняется. Ну и если вы попробуете максимально быстро посчитать количество предложений/строк/слов/букв в 10Гб текста то упретесь в производительность носителя (hdd, сеть, память), а не производительность процессора. На объемах до 100кб разница будет не большой, и беспокоиться тут не о чем. Но, если вдруг, в вашей задаче необходимо много раз вычислять длинну слов/строк/предложений, то вариант с перекодированием в fixed-width, и/или хранением мета-информации, и/или precalculated values будет оптимальнее (в большинстве случаев в не зависимости от кодировки)...
Variable width удобнее передавать по сети, а fixed width удобнее обрабатывать. И если вы забиваете гвозди микроскопом - то это ваша проблема, а не микроскопа. Не надо использовать utf-8 там, где оптимальнее использовать другой вариант кодирования.
Мне кажется, что utf-8 решает гараздо больше проблем чем создает. И благодаря именно этой кодировке мы все медленно, но верно переходим на юникод. Поэтому ваше утверждение о том, что "utf-8 – это ужасно" – не совсем корректно.
p.s. кажется увлеклись ,-)
Вроде по-русски написали, что внутреннее представление строк обычно не utf-8, а UCS в которой длинна символа фиксированна.
"...приходится проходить всю строку или нужно хранить метаинформацию..."
Избыточность при хранении длинны строки вместе со строкой не значительна. Посколько cstrings должны заканчиваться \0x0 символом, то разница в 1-3 байта на строку для хранения размера - не столь существенна.
UTF-8 ужасен? С тем же успехом, можно утверждать что данные по ethernet следует передавать азбукой морзе. А трафик дешевеет во многом благодоря именно новым методам кодирования информации.