Забавный но досадный глюк

[alexey38]

у тебя есть примеры таких программ?

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

[hovadur]

секунды, минуты, часы, дни

хотелось бы более точных чисел

[debi12345]

Хранить файлы в UTF8 и конвертить их в UCS2, в которой и выполнять строковые манипуляции и отображение = оптимальное решение, хотя бы потому дисковые операци = самые медленные операции, во время которых (i/o waiting) можно спокойно успевать конвертить только что прочитанную (подготовленную к записи) порцию данных.

[alexey38]

хотелось бы более точных чисел

Каких еще точных чисел?
Задача А выполняется 14,5 сек. Задача Б выполняется 2 часа 28 минут и 34 секунды. Задача С работает непрерывно в реалтайме, но требует железа не ниже определенного уровня, чтобы успевать обрабатывать.
Вот точные числа. Что Вы с этой информацией будете делать? Вы даже не знаете этих задач, их описание большое, а чтобы понять нюансы, чтобы понять почему сделано так, а не по другому, тот потребуется изучать вопрос целый год.

Добавлено спустя 2 минуты 22 секунды:

Хранить файлы в UTF8 и конвертить их в UCS2

Этот вариант здесь уже предлагался, при этом отмечалось, что в виду отсутствия ВОМа не всегда легко определить формат файла.

Добавлено спустя 3 минуты 25 секунд:

дисковые операци = самые медленные операции, во время которых (i/o waiting) можно спокойно успевать конвертить только что прочитанную (подготовленную к записи) порцию данных.

Кстати, по этой причине установка флага сжатия файлов в том же NTFS не снижает быстродействия операций ввода/вывода.

[runewalsh]

Задача А выполняется 14,5 сек. Задача Б выполняется 2 часа 28 минут и 34 секунды. Задача С работает непрерывно (...)
Вот точные числа. Что Вы с этой информацией будете делать?

Да вы, батенька, демагог! С вашей бы энергией...

Короче, запили уже реалистичный (в отличие от моего) бенчмарк, к примеру, поиск-замену по 100 Мб текстовому файлу с внутренней кодировкой на выбор из UTF-8 и UCS-2. Сомневаюсь, что даже с кандзи ты получишь разницу больше чем в 2-2.5 раза. Половинку прибавил, потому что в UTF-8 такие файлы на треть больше, чем в UCS-2.

[alexey38]

Короче, запили уже реалистичный (в отличие от моего) бенчмарк, к примеру, поиск-замену по 100 Мб текстовому файлу с внутренней кодировкой на выбор из UTF-8 и UCS-2. Сомневаюсь, что даже с кандзи ты получишь разницу больше чем в 2-2.5 раза. Половинку прибавил, потому что в UTF-8 такие файлы на треть больше, чем в UCS-2.

Демагог - это Вы. Умеешь писать проги - бери, пиши и проверяй, сколько угодно. Зачем сомневаться, зачем гадать - возьми и проверь в реальности. Я это делал на реальных проектах, знаю результат, поэтому не гадаю и не фантазирую как Вы.
Вместо этого Вы чего-то там хотите, чтобы кто-то удовлетворял Ваше любопытство. Если не умеете программировать сами, то чего тут сопли жуете. Если Вы верите в быстродействие UTF-8 - Ваше право, как хотите, так и делайте свои проекты, я же не заставляю Вас чего-то переделывать. Но Вы не обладая реальной информации начинаете спорить, вводите в заблуждение других, кому была интересна практическая информация.
Не понимаю, что за желание в пустую спорить ради спора? Даешь железный аргумент, а в ответ эмоции. Тут технику, а не лирику обсуждают.

[runewalsh]

Не-а, фантазируешь здесь ты. Потому что реальных цифр так и не привёл, зато говоришь о мифических "порядках", которым взяться просто неоткуда.

[alexey38]

Не-а, фантазируешь здесь ты. Потому что реальных цифр так и не привёл, зато говоришь о мифических "порядках", которым взяться просто неоткуда.

Вам что нужно выложить? Код, базы данных, инструкции по эксплуатации или что? Какие цифры? Да и цифры я называл: Задача А выполняется 14,5 сек. Задача Б выполняется 2 часа 28 минут и 34 секунды. Задача С работает непрерывно (...). Чем Вас это не устроило.

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

Ваша вера или невера, мало кого волнует. Вы главное дезу не распространяйте, и все будет хорошо. А то понтуетесь и народ смущаете. Есть у Вас есть реальная инфа, есть реальные примеры быстрого кода для UTF-8, давайте ссылки, предлагайте. А если только большое воображение и желание спорить, то есть другие площадки, соцсети и прочие отстойники.

[debi12345]

Разница "в порядки" нереальна 2 раза - реально.
Но для проянения вопроса предлегаю написать программу случайного регистро-независимого поиска 2000 слов в 10 МБайтном текстовом файле в разных кодировках - которые легко получить через "ICONV -f .. -t .."

[runewalsh]

Да и цифры я называл

С потолка, угу. Что за "Задача А", "Задача B"? Приведи хотя бы характеристики текста и время обработки. Их нет? А, ну извините.

то все это тогда еще вылезло

Не все алгоритмы, работающие с однобайтовой кодировкой, можно переписать на юникод в лоб с сохранением эффективности — потенциально наткнёшься на то же индексирование за O(N) вместо O(1). В boost даже есть концепция "unicode iterator". Но покажите мне человека, которому будет не лень этим заморачиваться, если итератором служило целое число.

P.S. Судя по странным нападкам в мою сторону, тебя забанили в гугле. Поэтому приведу пару ссылок.
1. "It seems that such bugs are extremely easy to find in many applications that use UTF-16", "Yes, UTF-16 should be considered harmful", "Virtually all string processing is sequential, not random", etc. etc. http://programmers.stackexchange.com/qu ... ed-harmful (об этом я и говорил изначально — UTF-16 создаёт ложное чувство безопасности, в итоге кое-кто из вас уже называет всё, что вне Basic Multilingual Plane, алфавитами инопланетян).
2. "Unicode implementations supporting only the Basic Multilingual Plane cannot handle all of the JIS X 0213 characters". http://en.wikipedia.org/wiki/JIS_X_0213

P.P.S. "Валидность данных несоизмеримо важнее производительности".

[debi12345]

об этом я и говорил изначально — UTF-16 создаёт ложное чувство безопасности

Хоть один пример (опасного) промаха индексированнго доступа с UCS-2 Это доступ работает и при размещении в "куче", и в свопе,... То есть везде и всегда.

в итоге кое-кто из вас уже называет всё, что вне Basic Multilingual Plane, алфавитами инопланетян).

А как еще назвать алфавит, нацеленный на быстрое внедрение несуществующих (на планете Земля) алфавитов в устройства отображения ? Именно предвкушение контакта с эльенами

Добавлено спустя 3 минуты 8 секунд:

Because about 300 kanji are in Unicode Plane 2, Unicode implementations supporting only the Basic Multilingual Plane cannot handle all of the JIS X 0213 characters.

Однако недоцитировано до конца:

This isn't an issue for most applications, however.

Японцы тупо не используют эти выждуманные (ихними националитсами ?) в 2000 году символы

[alexey38]

С потолка, угу. Что за "Задача А", "Задача B"? Приведи хотя бы характеристики текста и время обработки. Их нет? А, ну извините.

Данные не с потолка, а реальные, т.е. фактические. Что за задача А, Б, С - это задачи связанные с управлением и оптимизацией технологических процессов или функций действующих предприятий. Некоторые характеристики я приводил, суточный объем новой первичной информации около 1 Гб. Объем ретроспективной информации более 1 Тб. Объем исходников всех проектов от А, до некого Я, около 500 Мб. Характеристика текста - русские, английские буквы и цифры. Тексты в разных задачах разные. Смысл задач новый сотрудник понимает примерно через 2-3 месяца после устройства на работу, при условии профильного образования (не программистсткого), без профильного образования (программист) вникает в задачу примерно через 1 год.

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

Добавлено спустя 22 минуты 22 секунды:

Не все алгоритмы, работающие с однобайтовой кодировкой, можно переписать на юникод в лоб с сохранением эффективности — потенциально наткнёшься на то же индексирование за O(N) вместо O(1). В boost даже есть концепция "unicode iterator". Но покажите мне человека, которому будет не лень этим заморачиваться, если итератором служило целое число

Наконец Вы от эмоций и голословных абстракций перешли в плоскость практики. Нужно переписывать код под уникод. Общий багаж кода в мире таков, что до сих пор Фортран и прочее существует. Переписать можно, но это теоретически, т.к. никто за это не хочет платить.

Наличие концепции - это лирика. Практика в том, что существующий функционал строковых библиотек в ФПС, Лазаре и Дельфи таков, что нет инструментария, кроме говнокода, для банального последовательного перебора символов. Можно писать код с использованием указателя на PUTF8Char, но это и будет говнокод с стиле сишной строковой арифметики. Как на ассемблере написать быструю уникодовскую обработку без ухудшения стиля - мне понятно. Но приведите быстрый паскалевский код, для последовательного перебора символов в строке или для множественного поиска в строке с продолжением. Вот две распространенных функции, реализация которых в классическом виде слишком медленная. Если бы индексация строки была не по целому числу, а при помощи класса, в котором хранилось бы не только номер символа, но и его смещение, то без вопросов, но в реальности такой реализации нет. Вот и думаешь, что делать говнокод, или просто реализовать на UTF-32 и не заморачиваться. Для строго русских задач подойдет UTF-16, не гарантия, но для практики применимо.

Добавлено спустя 4 минуты 14 секунд:

P.S. Судя по странным нападкам в мою сторону, тебя забанили в гугле. Поэтому приведу пару ссылок.

Если бы Вы не гнули пальцы, а перечитали всю эту тему, то там об этом не раз говорилось. Поэтому повторю еще раз. Для русского языка в его нынешнем виде, можно смело пользоваться UCS16, но в мультиязычной постановке только UTF32. А там, где гарантированно только английский текст, то там можно пользоваться обычными 8-битными строками.

[runewalsh]

Хоть один пример (опасного) промаха

По первой ссылке, что я привёл. Опасность не для целостности памяти, а для валидности данных, когда программист считает, что UCS-2 достаточно. Пусть хоть 99.999% всего текста в мире выражаются в UCS-2, это не повод выбрасывать остальные 0.001%. А то, по вашей же логике, если гонка проявляется в 1 случае из (да скольки угодно), её можно не исправлять.

несуществующих

Сколько можно. -_-" Там не только древняя письменность, но и специфические символы (математические или там игровые).

Кандзи не выдумываются, а заимствуются из китайского. "Very rarely-used" ни разу не значит "not used". "This isn't an issue for most applications, however" — видите ли, для локального использования у японцев свои костыли, тот же Shift-JIS — но это не юникод (хотя идеей напоминает UTF-8), недостатки и несовместимость в обе стороны с другой локалью у них ровно те же, что у ANSI. Разговор как раз о том, как от этого уйти.

А alexey38, похоже, вздумал пугать меня сложностью задач (месяцами вникать, в NASA работаете?) и даже привёл-таки цифры, только среди них опять нет тех, что я просил.

Наличие концепции - это лирика.

Что? Подучи-ка терминологию. Я понимаю, что в контексте паскалей кажется невозможным само существование библиотек вроде Boost, но они есть и работают. И без говнокода, удивительно, правда?

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

Хоспаде, даже без C++-стайл итераторов кто тебе мешает использовать то же число, но в качестве индекса байта, а не символа?

Для русского языка в его нынешнем виде, можно смело пользоваться UCS16, но в мультиязычной постановке только UTF32. А там, где гарантированно только английский текст, то там можно пользоваться обычными 8-битными строками.

Предлагаешь вернуться к аду с 9000 кодировок? Зато в каждой отдельно взятой по байту на символ, чо. Я не буду расписывать, почему одна универсальная (или 2, со взаимно комплементирующими свойствами) лучше — т. к. ты этого в упор не понимаешь.

[SeZuka]

Уже достали со своими спорами, накидал небольшой тест для ленивых.
1. Создается файл из N-миллионов случайных символов и сохраняется в UTF-8.
2. Грузим этот файл в память и далее сам тест для UTF-8 и UTF-16:
2.1 Преобразование к верхнему регистру;
2.2 Преобразование к нижнему регистру;
2.3 Определение длины в символах
2.4 Получение подстроки
2.5 Поиск этой подстроки
Для теста UTF-16 вначале теста производится преобразование UTF-8 -> UTF-16 и в конце теста обратное преобразование.

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

Интересный факт из теста: функция UTF8UpperCase работает в 4 раза дольше чем UTF8LowerCase, косяк в алгоритме или кривые руки программистов?

[alexey38]

NASA работаете?

Не совсем, но задачи близкие, масштаб проектов (не программные) и их бюджеты превышают бюджет НАСА.

Добавлено спустя 1 минуту 6 секунд:

Я понимаю, что в контексте паскалей кажется невозможным само существование библиотек вроде Boost, но они есть и работают.

В паскале? Возможно есть, так приведите название библиотеки и функции.

Добавлено спустя 46 секунд:

кто тебе мешает использовать то же число, но в качестве индекса байта, а не символа?

Это разве реализовано в стандартной строковой библиотеке?

Добавлено спустя 2 минуты 2 секунды:

Предлагаешь вернуться к аду с 9000 кодировок?

Предлагаю использовать в базе UTF32, и из него уже формировать нужные кодировки, когда нужно куда-то сохранять и передавать. Тогда будет универсальный алгоритм на все случаи жизни. Весь существующий код будет совместим, если под типом String = StringUTF32.