Eugene New- невозможность доступа по индексу

Доступ к элементу по индексу - это частный случай. Я-бы обобщил до операций




Это - универсал. Пуля из серебра. Если мы докажем ее средне-статистическую эффективность для
строк с плавающей кодировкой типа utf-8 то все conserns должны отпасть сами по себе.

Расмотрим кейс миграции с win-1251 на utf-8 и эту волшебную функцию и потери на памяти.

Поинты:

1) В средне-статистическом приложении строки обычно не очень длинные.

Коллеги кто можеть оценить (сделать мемори дамп) для С++ приложения и сказать сколько там длины.
Среднее. Максимум. Если гистограмма - вообще замечательно.



Я могу (теоретически) сделать дамп для Java но это какраз не наш кейс. Java не будет мигрировать строки на utf-8.
У нее другой подход (я приводил сорцы).



2) Пример парсинга URL - хороший. Но где там индексный доступ? Если мы применяем регулярку
то автомат разбора который будет сгенерирован регуляркой обычно применяется к исходной строке
поточно. Слева направо как и работают все синтаксические машины. Следовательно индексный доступ
к произвольному элементу - не важен. Если есть итератор char * который стоит и смотрит на первый
символ то его достаточно чтоб решить данную задачу.

Если мы детектируем протокол (хедер строки) то вызов substr(m,n) вырождается до substr(0,n).







Кто не согласен что достаточно - оппонируйте.

3) Перформанс случаев применения substr(m,n) к utf-8 содержимому баз данных .
Не окажут какого либо сильного воздействия на перформанс. Основная нагрузка будет идти на I/O и на физическое
вычитывание блоков сегмента таблиц. Я вангую что нагрузка на CPU может поднятся в диапазоне
от 0 до 50%. А время отклика - практически не изменится. Тоесть ожидали вы отчот 1 минуту с win1251
и после миграции колонки на utf-8 так-же будете ждать минуту.

4) Проигрыш памяти БД. Здесь для баз данных в целом пофиг. Это экспертно . Я просто давлю на то
что содержимое строк не покрывает сегмент данных на 100%. Есть другие типы и прочее.
Кроме того средняя БД практически никак не реагирует на изменение длины данных в строках.
Много дыр в сегменте данных. Много технических гистерезисов которые так просто в двух
словах не объяснить. В целом - не реагирует. Конечно 90% зависит от того как грамотно
вы провели конвертацию. Что делали после drop column и прочее. Характеристики блоков сегмента...

5) Проигрыш оперативной памяти для приложений . Здесь тоже нужна статистика. Нужно посчитать % соотношение Latin
и кириллицы и взять нечто взвешенное. Это тоже дополнение к пункту (1)

Я вангую что если у вас было С++ приложение работающее с win-1251 и вы его адаптировали
к utf-8 то особого проигрыша памяти не будет.

6) Некий гипотетический worst-case. Мы будем искать суффикс.


Ну... где это может быть полезно? Я не знаю. Младшие разряды. В телефонном номере 5 или 7 последних цифр.
Не знаю. Тут надо архитектурно подумать. Может хранить телефон в реверсивном формате. Может разделить
мобильный оператор и номерную ёмкость в отдельные поля БД и в бизнес-сущностях.

Вобщем зубодробилка существует. Но ее надо обсуждать.

booby, только начал смотреть. Сразу возник вопрос. Эдакий машинальный code-review point который меня блочит.



Почему pc_stacker объявлен как OUT ?

Ы22) Посмотрите уже, наконец, что не 66 букв надо на кириллицу. Там за сотню точно уйдет.
3) Навскидку, не менее 40 (и этим пользуются).

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

В принципе сошла-бы верхняя граница. Например - не более 150. Или не более 200.

По третьему - спс.

boobymayton,

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

способ оформления - функция или процедура, в данном случае это сахар с запахами, к делу не относится.
но в той искусственной "учебной" истории изначально говорилось о функции,
потому так и пересказываю.
Мне непонятно также почему используется LONG. Это морально устаревший тип и его заменяют обычно на BLOB.

Мне не очень понятен вход и выход.

Я так себе вижу. На вход подается




На выходе в консоли мы получаем. Хм... а что мы получаем? Непонятно.



Прошу прощения я всегда привых рассматривать задачу с верхнего уровня. С уровня смысла так-сказать.

boobymaytonпропущено...

ОК. Спасибо. Почитаю.
нашел ссылку:
https://www.oracle.com/technetwork/products/globalization/efficient-plsql-133329.pdf
Для AL32-UTF-8 Length посчитан как o(m).

Маху дали. Можно было добавить свойство длины и получить константу. Это привело-бы
к небольшому увеличению структуры данных для NVARCHAR на пару байтов. Пожадничали?
На серваках БД по 128 Гиг щас ставят. Мдя...

Вот мысль. Для Евгения. Фантазируй бро.

Ы2Насчет количества знаков для кириллицы. Очень грубый подсчет дает ~85 графически разных букв, имеющих прописное и строчное написание, и ~5 знаков с единственным вариантом. Итого, не менее 175 штук. Думаю, оценка сверху в 200 знаков даст запас, но не очень большой.

В латинице можно считать ~60 дополнительных знаков к основному набору. То есть примерно те же 200 знаков. Можно заметно сократить, используя комбинируемые диакритические знаки. С кириллицей тоже должно сработать, но все равно в 256 символов не уложиться.
Отлично.

Нам нужно сохранить нижнюю половину таблицы полностью. Тоесть 128 симвлов оставить как есть.
+ 200 знаков для всех киррилических языков мира

Итого 328 знаков.

Укладываемся в 9 битов. (не более 512 состоянии и еще запас есть)

9 и 8 считаем наименьшее общее кратное 9 и 2*2*2 вобщем просто произведение 72 бита.
Тоесть 9 байтов кодируют 8 символов. Формула не очент красивая. Не получилось выровнять
на четные границы адресов. Но зато почти o(1) доступ.

Далее можно попробовать еще вариант с множителями как в base85.

Eugene NewКак она может не реагировать, когда вам приходится делать все строковые поля в ДВА раза большего объема. Не писать туда больше, а сразу увеличивать длину полей в байтах в два раза. Раньше надо было 100 байтов, теперь надо 200. Потому что поле может достигать 100 символов длиной на русском языке.
Если вы используете русский язык в базе. Для латиницы, повторяюсь, все равно. Для русского языка - катастрофичное увеличение объема.
Как я уже писал. Сегментное пространство таблиц состоит из смеси VARCHAR, NUMBER, DATE типов и прочих сырых типов и служебной информации и пустого места. Из оставшися VARCHAR типом вы выкинем всякие GUID телефоны адреса электронки и бизнесовые идентификаторы которые пробиты латиницей.

Каждый мой шаг можете отмечать некой примерной оценкой (например брать 1:4). Тоесть на каждый кирилический типа будет 4 латинских. На каждое VARCHAR поле будет 4 не-варчар. Или берите другое соотншение. Пофиг. Важно что деля этот объем
сегмента на порции я вам показываю что на самом деле кириллица не может занимать много места изначально.

(Если у вас не библиотека Мошкова в базе).

Все это мои предположения на основе моего видения СРЕДНЕСТАТИСТИЧЕСКОЙ базы. Торт с названием база я режу на
кусочки и каждый кусочек тоже на кусочки.

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

Eugene NewЭто другая задача. Более затратная чем s [n]. То есть меняя s [n] на substr(m,n) мы сразу теряем.

Это неважно. Я-же генерализировал ваше требование. Взял тот сет функций который опирается
в на жалкую и ничтожную s[n] которая мало полезна сама по себе. Мало кому нужен 20-й символ.
А вот взять с 0 по 4-й - это нужная задача особенно когда мы парсим протокол URL.

Eugene NewДаже если они не длинные, то их много и они занимают много места. Строки обычно всегда оказываются первым узким местом по расходу памяти.
Я писал выше что в средне-статистическом java-приложении сегмент char[] является самым толстым по потреблению.
Но не забывайте что рантайм jvm (classloader) складывает туда толстные названия пакетов + классов. И анонимных классов.
Тоесть масса служебной инфы кроме прикладной. Это только особенность JVM.

Хотя для некоторых приложений int[] иногда выходил наверх.

Для других языков и технологий C++/.Net/Python/ e.t.c. я такой статистики не знаю. И я прошу знатоков
этих технологий дать нам в топик сведенья.

А сколько собственно строк и каков их средний размер?

Eugene Newавтомат разбора

Усложняется и это частный случай.

Я не принимаю этот аргумент. Где justification? Документация? Фрагмент кода?

Eugene NewПроигрыш оперативной памяти для приложений.
чем больше используют русский язык, тем хуже.
Это просто прекрасно! Из этого можно сделать вывод что не стоит использовать русский язык.
Будьте осторожны с тезисами. Я - же хочу числовую оценку. А вы просто сообщаете банальность.

Basil A. SidorovmaytonНу... где это может быть полезно? Я не знаю. Младшие разряды. В телефонном номере 5 или 7 последних цифр.Я напоминаю, что UTF8 обратно совместима с US-ASCII.
Практически это означает, что целый пласт алгоритмов для US-ASCII переносятся на UTF8 без каких-либо модификаций.
Это и ваш "поиски последних цифр телефонного номера" и "разбиение файлового пути по элементам" и т.д. и т.п.
Прошу прощения. Они то совместимы. Но до того как мы начали поиск суффикса в UTF8 - мы не знаем
что внутри строки. Хотя упрощение - справедливое. Да.