Хм, я думаю, что если поискать, то можно что-то интересное найти.

Вот например, они обсуждают аспекты кэширования.

https://github.com/mitmath/18S096/blob/master/lectures/other/Transposition.ipynb

То есть конечно, они где-то в performance tips говорят, что порядок операций и расположение данных в памяти влияет на производительность, но знать одно, а понимать как это работает на практике - другое.

Кстати, вот ещё интересная лекция https://www.youtube.com/watch?v=mSgXWpvQEHE

Вроде у нас не было в канале.

практика - это очень специфическая штука…. Если откровенно, то с Julia, мы находимся в стадии, когда мало кто может поделиться глубоким личным опытом. Опыт в основном из других языков программирования и технологий. Осваивать же чужой опыт целиком, скорее, бесполезное занятие, если этот опыт не имеет реального применения….

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

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

сейчас смотреть целиком некогда. К DSL на Julia у меня претензия в том, что язык то на ней написать можно, но внутри - это разбор выражения, контроль за которым полностью лежит на программисте. Включая разбор строк и исполнение кода, в некоторых случаях. С точки зрения программирования - полное безобразие…. У меня в качестве противоположного примера - Ruby. Какой бы DSL на нём ни написали, он останется Ruby, но распознать в нём Ruby не всегда просто. Зато Ruby на себя возьмёт контроль и синтаксиса, и исполнения

Да, знаю этот пакет разумеется.
У них свои проблемы.

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

ну тогда их штатные строки - это как раз низкоуровневое представление

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

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

Да, вычислять можно.
Но это сводит на нет весь перформанс.

То есть по факту есть несколько вариантов.
Эффективный по памяти - то, что сделано в языке. По производительности - супер плохо
Максимально неэффективный по памяти - UInt32 представление. По производительности - отлично, но тратишь время на перевод из одного представления в другое.

Промежуточный вариант (как это сделано в python и других языках) - это Union 8/16/32 битного представления. Быстро, но управлять сложно.

В общем, есть свои проблемы.
Но мне вариант, который разработчики выбрали не понравился в итоге. Я пытался выжать всё, что мог, но всё равно, вычисление - это долго, с прямым обращением по памяти не сравнится.

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

Потому что по факту, если основная задача - это обработка текста, то только фиксированный размер.
Но получается, что об этом надо всегда помнить и заботиться. Это неудобно.

Ну, то есть у меня всё было на nextind написано, а как только я сконвертировал в полный размер, то скорость выросла в 2-3 раза сразу.

ну… я бы тоже предпочёл, чтобы они не называли String строкой. Но, можно же обернуть контейнером или конвертнуть в фиксированную длину