Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 41
utf-16 в плане производительности не уступает cp1251.
Однако, конечно, 2 байта держать там, гед можно обойтись чаще всего одним бывает накладно.
Однако, конечно, 2 байта держать там, гед можно обойтись чаще всего одним бывает накладно.
utf-16 уступает в производительности. Конечно потому, что надо анализировать в два раза больше байт, но и потому, что utf-16 — это не два байта, это кодировка с переменным количеством байт на символ, поэтому нельзя просто написать i+=2 и перейти к следующему символу.
Как раз UTF-16 занимает ровно 2 байта, а вот UTF-8 имеет переменную длину от 1 до 6 байт.
Совершенно непонятно, за что наминусовали taldy. UTF-8 действительно имеет переменную длину в 1-6 байт. Можно было бы сослать на спецификацию, но я предлагаю заглянуть хотя бы в вики ru.wikipedia.org/wiki/UTF#UTF-8
utf-32? :)
многое от реализации зависит. год тому назад сравнивал www.gnu.org/software/coreutils/ и heirloom.sourceforge.net/tools.html, и последние на отдельных юникодных тестах выигрывали в несколько раз.
Надо же, хотя бы в конце текста упомянул, хоть и мельком, что речь идет про php. Что за БД, вообще ни слова. Ну я понимаю, для вас web = php + mysql, no exceptions
думалось что в тэгах достаточно, спасибо, сейчас будет добавлено
Вопрос — а нахуа у вас в БД столько текста? У вас там либрусек портабельный, что ли? Я всегда думал, что текст — это презентационная логика, как и разметка => оно, в основном, лежит в файлах/шаблонах.
Если у вас магазин диких размеров с таким набором товара, то экономить на utf-8, это… ну я не знаю, как это… что-то не так в датом^W даццком королевстве
Если у вас магазин диких размеров с таким набором товара, то экономить на utf-8, это… ну я не знаю, как это… что-то не так в датом^W даццком королевстве
БД — блоги.
Что касается экономии. При условии что utf избыточен, то в коммерческом продукте однобайтовая кодировка это бесплатный способ сделать сайт чуть быстрее. А в некоммерческом, живущем на самоокупаемости и не более, это может оказаться гранью между выживанием и закрытием.
При чем экономия-то может получится не такая маленькая. Да, есть цифры типа 1.09х, но есть и 6.42х.
Что касается экономии. При условии что utf избыточен, то в коммерческом продукте однобайтовая кодировка это бесплатный способ сделать сайт чуть быстрее. А в некоммерческом, живущем на самоокупаемости и не более, это может оказаться гранью между выживанием и закрытием.
При чем экономия-то может получится не такая маленькая. Да, есть цифры типа 1.09х, но есть и 6.42х.
А если это некоммерческий, то откуда там заказчик, с которого выбивать деньги? :)
Оффтопом: всегда думал, что контент блогов лежит пожатый в БД
Оффтопом: всегда думал, что контент блогов лежит пожатый в БД
Блоги?
Тогда ваш метод расчета некорректен (точнее, неполон). Образно говоря, вы считаете крейсерскую скорость и делаете из нее выводы о времени, необходимом на прибытии из точки А в точку Б, совершенно забывая о светофорах, пробках и поломках на дороге.
Что такое «скорость» с точки зрения пользователя вашего блога? — Время, требуемое на загрузку страницы. Давайте постараемся учесть чуть больше факторов:
— HTML-entities + ударения (combined diacriticals). У вас ведь есть парсер, который всякую юникодную лабуду (¹²³≠±…) амперсандит и разамперсандит? В случае использования utf8 он как бы без надобности; а копи-паст заголовка из википедии почти с гарантией содержит ударение, например. Я уж молчу, что «Ива́ново» вы в cp1251 в базе не найдете никогда.
— дополнительная обработка полей ввода (вам же нужно что-то специальное сделать с паролем «fúck§mě», не так ли?) + танцы с бубном вокруг случаев, когда пользователь вводит вперемешку utf8 и entities (пользователь обычно ожидает при редактировании записи увидеть тот текст, который вводил, а не тот, который вам удобно хранить в базе).
Если вторая проблема кажется вам надуманной, то посмотрите, как оно реализовано в ЖЖ/ya.ru — именно так, как я говорю, а значит — пользователи к этому привыкли. Сиречь, вам нужно вводить какие-то дополнительные поля типа «raw input» и обрабатывать их при каждом показе страницы редактирования.
Это только навскидку. Отсюда, внимание, вопрос: вы уверены, что накладные расходы себя оправдают?
Тогда ваш метод расчета некорректен (точнее, неполон). Образно говоря, вы считаете крейсерскую скорость и делаете из нее выводы о времени, необходимом на прибытии из точки А в точку Б, совершенно забывая о светофорах, пробках и поломках на дороге.
Что такое «скорость» с точки зрения пользователя вашего блога? — Время, требуемое на загрузку страницы. Давайте постараемся учесть чуть больше факторов:
— HTML-entities + ударения (combined diacriticals). У вас ведь есть парсер, который всякую юникодную лабуду (¹²³≠±…) амперсандит и разамперсандит? В случае использования utf8 он как бы без надобности; а копи-паст заголовка из википедии почти с гарантией содержит ударение, например. Я уж молчу, что «Ива́ново» вы в cp1251 в базе не найдете никогда.
— дополнительная обработка полей ввода (вам же нужно что-то специальное сделать с паролем «fúck§mě», не так ли?) + танцы с бубном вокруг случаев, когда пользователь вводит вперемешку utf8 и entities (пользователь обычно ожидает при редактировании записи увидеть тот текст, который вводил, а не тот, который вам удобно хранить в базе).
Если вторая проблема кажется вам надуманной, то посмотрите, как оно реализовано в ЖЖ/ya.ru — именно так, как я говорю, а значит — пользователи к этому привыкли. Сиречь, вам нужно вводить какие-то дополнительные поля типа «raw input» и обрабатывать их при каждом показе страницы редактирования.
Это только навскидку. Отсюда, внимание, вопрос: вы уверены, что накладные расходы себя оправдают?
дополнительная обработка полей вводаФильтрация ввода от пользователя нужна в любом случае, поэтому обработка полей вводе не является дополнительной опцией и не является минусом.
танцы с бубном вокруг случаев, когда пользователь вводит вперемешку utf8 и entitiesХабрапарсер, форумы на vbb/ipb с Вами не согласятся по поводу «привыкания» пользователей.
молчу, что «Ива́ново» вы в cp1251 в базе не найдете никогда
посмотрите, как оно реализовано в ЖЖ/ya.ru — именно так, как я говорю, а значит — пользователи к этому привыкли.
Но даже по ЖЖ, по Вашему совету было проверено
И как-то не всё так однозначно как Вы говорите:
1) В визуальном редакторе все вроде бы ок…
2) Однако уже в html виде видны «сущности» и «отдельные ударения»…
3) Как это выглядит в html коде ЖЖ — жуткая жуть…
4) Поиска родного у ЖЖ нет вроде? Но яндекс ищет «Ива́ново» как «Ива'ново», а вот сейчас на хабре знак ударения при написании коммента стоит вообще над «н», хотя в превью уже над «а»… и непонятно что будет после отправки.
Отсюда, внимание, вопрос: вы уверены, что накладные расходы себя оправдают?Иногда оправдают, иногда нет.
Целью публикации было показать какие именно потери по производительности в БД возможны в случае выбора utf там, где достаточно cp1251, что бы каждый для своей ситуации мог бы сделать оптимальный выбор.
Целью публикации было показать какие именно потери по производительности в БД возможны в случае выбора utf
Эта цель, безусловно, достигнута, и спасибо вам за это — это интересно.
там, где достаточно cp1251, что бы каждый для своей ситуации мог бы сделать оптимальный выбор
А эта, на мой взгляд, раскрыта не полностью — отсюда и мой комментарий.
Да, не все ладно пока с хабрапарсером и форумами. Да, бесспорно, я описал «идеальный мир в лебеговом пространстве после конца света». Но Яндекс ищет Ива́ново хоть как-то, а вам придется вбивать для этого костыли в ваш поисковый движок (чтобы найти «Ивaĭ ново»). То, что видны и сущности и «отдельные ударения» — это правильное поведение (вам показывают ровно то, что вы ввели).
P. S. По поводу проверки полей ввода: я не говорил, что они внезапно появятся, я говорил, что они усложнятся.
Только по моему яндекс просто игнорирует букву с ударением. А в заголовке яндекса все равно написано «Ива'ново». Так же, думаю, количество людей, которые ищут так слова с ударением не много. Наверное по простой причине: что этот символ нельзя быстро на клавиатуре набрать.
Примо. Я говорил не про то, что ищущие «Ива́ново» обломятся, а о том, что адепт типографики обломится со своим «Ива́ново» — он не попадет в выдачу по слову «Иваново».
Секундо. Все люди, которым хоть сколько-нибудь дорог язык во всех его проявлениях — давно набирают акценты с клавиатуры. Это не так сложно.
Секундо. Все люди, которым хоть сколько-нибудь дорог язык во всех его проявлениях — давно набирают акценты с клавиатуры. Это не так сложно.
Правильно. Цели использования utf8 несколько другие, чем скорость работы с бд. Это как если бы говорить, что надо использовать компилируемые ЯП вместо скриптовых: генерите странички на C++ ибо PHP в разы медленней (и памяти жрет в разы больше).
Второй момент, если замедление работы некоторых не самых используемых запросов к бд всего в 2 раза стало критичным, значит сайт неправильно спроектирован.
Второй момент, если замедление работы некоторых не самых используемых запросов к бд всего в 2 раза стало критичным, значит сайт неправильно спроектирован.
Для полноты эксперимента, стоило бы добавить в таблицу строку «Добавление поддержки немецкого/китайского/… языка в систему, заточенную под cp1251».
Если под cp1251 заточена только база (что дает ровно те преимущества по скорости что описаны), а скрипты написаны под utf (например как описано тут в комменте), то смена кодировки на utf займет:
написание строк mysqldump/mysql — 97.4 секунды (примерно)
mysqldump экспорт в файл 8.8 сек (1251)
mysql импорт из файла 13.8 сек (utf)
Итого: 2 минуты:)
написание строк mysqldump/mysql — 97.4 секунды (примерно)
mysqldump экспорт в файл 8.8 сек (1251)
mysql импорт из файла 13.8 сек (utf)
Итого: 2 минуты:)
Правда, при этом база немного потеряет описанные вами преимущества, что, как бы, не совсем решение той задачи, которую поставил YasonBy.
Потому что поддержка — не всегда локализация. К вам может прийти пользователь по имени «Bjørnstjerne Martinus Bjørnson» с цитатами из своей «På guds veje».
Потому что поддержка — не всегда локализация. К вам может прийти пользователь по имени «Bjørnstjerne Martinus Bjørnson» с цитатами из своей «På guds veje».
Еще конечно интересно было бы иметь кроме столбца среднее, столбцы — лучшее/худшее
Неплохая статистика. На собственном опыте убедился, что памяти приложения utf-8 «съедают» на 30-40% больше, чем на cp1251.
Но (!):
— Во-первых, неглючного AJAX приложения с использованием cp1251 не сделаешь. При переброске сложных данных (например, данные форм), частенько iconv даёт весьма корявые результаты.
— Во-вторых, обменивается клиент и сервер в основном небольшими текстовыми блоками, так что весь profit в скорости от использования cp1251 съедается потерями на iconv.
В итоге лучше иметь неглючное приложение на utf-8, чем примерно такое же с возможными глюками на cp-1251.
Но (!):
— Во-первых, неглючного AJAX приложения с использованием cp1251 не сделаешь. При переброске сложных данных (например, данные форм), частенько iconv даёт весьма корявые результаты.
— Во-вторых, обменивается клиент и сервер в основном небольшими текстовыми блоками, так что весь profit в скорости от использования cp1251 съедается потерями на iconv.
В итоге лучше иметь неглючное приложение на utf-8, чем примерно такое же с возможными глюками на cp-1251.
Неплохой промежуточный вариант: приложение на utf, а база в cp1251. при set names utf затраты на перекодировку ничтожно малые (пусть даже с десяток строк запросов конвертнуть туда сюда), а производительность БД будет именно как с cp1251, что ощутимо.
> utf может быть как ru_RU.UTF так и en_EN.UTF, что дает забавные эффекты с iconv //ignore //translit, уж бог знает почему
Потому, что ru_RU и en_EN в данном случае задают culture — сортировку символов, преобразование регистра, форматы чисел, валют и т.д.
Потому, что ru_RU и en_EN в данном случае задают culture — сортировку символов, преобразование регистра, форматы чисел, валют и т.д.
Потому, что ru_RU и en_EN в данном случае задают culture — сортировку символов, преобразование регистра, форматы чисел, валют и т.д.Точный пример вспомнить трудно, но если по памяти/аналогии привести пример «с потолка», то очень сильно смущает, что iconv Königsberg //ignore //translit может превратиться в Konigsberg, может в Ko'nigsberg, или допустим в K«onigsberg или даже в Koonigsberg в зависимости от локализации „универсальной“ кодировки UTF.
Не понятно какие типы столбцов были использованы (CHAR, VARCHAR или же TEXT и BLOB) и какие подсистемы.
Похоже, что в тестах вы использовали движок MyISAM, который сохраняет поля типа TEXT совсем не так, как сохраняет его движок InnoDB. А именно:
— В InnoDB используется покрывающий индекс, потому размер индекса может больше нежели в MyISAM
— В MyISAM используется FULLTEXT индекс, поэтому индекс по размеру должен больше нежели в InnoDB :-)
— Типы CHAR и VARCHAR более компактны и занимают меньше места в данных и в индексе
— В таблицах типа Memory строки всегда занимают максимальный объём, что существенно бъёт по производительности. Т.е. если указано VARCHAR(50), то таблица Memory выделит 150 байтов, так как не знает какой длины символы будут использоваться
— Та же проблема с индексами, где мы указываем ограничить индекс 100 символами, а MySQL урезает индекс до 33
Вообщем нужно больше данных что бы сравнивать и сравнивать…
Похоже, что в тестах вы использовали движок MyISAM, который сохраняет поля типа TEXT совсем не так, как сохраняет его движок InnoDB. А именно:
— В InnoDB используется покрывающий индекс, потому размер индекса может больше нежели в MyISAM
— В MyISAM используется FULLTEXT индекс, поэтому индекс по размеру должен больше нежели в InnoDB :-)
— Типы CHAR и VARCHAR более компактны и занимают меньше места в данных и в индексе
— В таблицах типа Memory строки всегда занимают максимальный объём, что существенно бъёт по производительности. Т.е. если указано VARCHAR(50), то таблица Memory выделит 150 байтов, так как не знает какой длины символы будут использоваться
— Та же проблема с индексами, где мы указываем ограничить индекс 100 символами, а MySQL урезает индекс до 33
Вообщем нужно больше данных что бы сравнивать и сравнивать…
Часть ответов на Ваши вопросы добавлена в статью. Результаты для InnoDB в общем те же что для MyISAM. Что логично.
Для memory таблиц используется char, т.к. blob и text не поддерживаются, а varchar работает так же как char. Кроме того, следует отметить, что varchar(50) в cp1251 будет использовать 50 байт против 150 в utf8, отсюда и различие в размерах и очевидно скорости.
Для обычных таблиц использовалось изначально MyISAM/text, сейчас добавлено и innoDB/text. С индексами InnoDB не тестировалась, т.к. фултекста там нет, а в varchar эту базу индексировать бессмысленно.
Для memory таблиц используется char, т.к. blob и text не поддерживаются, а varchar работает так же как char. Кроме того, следует отметить, что varchar(50) в cp1251 будет использовать 50 байт против 150 в utf8, отсюда и различие в размерах и очевидно скорости.
Для обычных таблиц использовалось изначально MyISAM/text, сейчас добавлено и innoDB/text. С индексами InnoDB не тестировалась, т.к. фултекста там нет, а в varchar эту базу индексировать бессмысленно.
Помойму эта экономия совсем не на том. Новичкам не рекомендуется.
На planet mysql видел запись о том что для полей несущих непосредственно тексты использовать utf, а для «ключевых» (константы, коды, enum) полей использовать ascii.
Использовать mysql для полнотекстового поиска само по себе странно. 99% запросов в большинстве проектов это выборки по каким-то идентификаторам. Если использовать нормальный фуллтекстовый поиск (Sphinx) то совершенно без разницы в какой кодировке выгружать. Небольшая разница в объеме врядли будет иметь серьезный эффект.
цп1251 конечно удобно (было в винхр), но когда однажды заказчик попросил сайт сделать еще и на китайском — было решено больше не делать ничего с национальными кодировками никогда… с тех пор и живу с обнимку с utf8 и не знаю горя с «у нас сайт криво показывает»
1. тупая статья. да простит меня топик-стартер.
2. преимущество утф над всеми другими кодировками перекрывает микроны скорости, которые даст переход на 1251.
3. простой пример, когда у тебя в в админке хотят уложить статью на иврите или типа того.
2. преимущество утф над всеми другими кодировками перекрывает микроны скорости, которые даст переход на 1251.
3. простой пример, когда у тебя в в админке хотят уложить статью на иврите или типа того.
А 32 бита больше, чем 8. Давайте все переходить на 8-битные компы! Память же надо экономить! И современные проги слишком прожорливы — не то, что «лексикон» под DOS!
Вы примерно к этому призываете, я правильно понял?
Очнитесь, наконец, 2011 год на дворе! UTF-8 это никакая не передовая технология. Это нормальное и логичное решение всех проблем с костылями и зоопарком кодировок.
Вы примерно к этому призываете, я правильно понял?
Очнитесь, наконец, 2011 год на дворе! UTF-8 это никакая не передовая технология. Это нормальное и логичное решение всех проблем с костылями и зоопарком кодировок.
UTF-8 это никакая не передовая технология. Это нормальное и логичное решение всех проблем с костылями и зоопарком кодировок.Не передовая, именно потому, что 100% решением не является на данный момент, имея набор своих, нерешенных проблем.
А 32 бита больше, чем 8. Давайте все переходить на 8-битные компы! Память же надо экономить! И современные проги слишком прожорливы — не то, что «лексикон» под DOS!Нет, не совсем правильно. Речь о том, что надо понимать, что работа с утф8 до 2 раз замедляет работу скриптов. Или до 2 раз удорожает ресурсы требуемые для их работы, что особенно заметно в облаках.
Вы примерно к этому призываете, я правильно понял?
Если эти затраты приемлимы или утф необходим, то вопросов нет — нужен утф. А если сайт не имеет необходимости в мультиязыковой кодировке и при этом имеет необходимость в ускорении работы или снижении нагрузки, то переход на однобайтовую кодировку это один из самых простых и дешевых способов. Оптимизация кода требует высококвалифицированного программиста, времени и рефакторинга, при том зачастую не дает даже 1/4 того эффекта, который может дать смена кодировки.
Спустя 14 лет, насколько изменилась ситуация?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скорость работы с utf, очевидное, но малоизвестное для новичков