IB
Size: a a a
2021 January 11
AK
конскольная утилита
Perl5-пакет нужен
AK
> data.users.0.creds.password
неудобно же будет узеров пихать
неудобно же будет узеров пихать
это тебе парсить строку каждый раз, инкрементить этот индекс
а если передумал и в середине коллекции удалил пару юзеров? пересчитывать все ключи что ли?
а если передумал и в середине коллекции удалил пару юзеров? пересчитывать все ключи что ли?
AK
это тебе парсить строку каждый раз, инкрементить этот индекс
а если передумал и в середине коллекции удалил пару юзеров? пересчитывать все ключи что ли?
а если передумал и в середине коллекции удалил пару юзеров? пересчитывать все ключи что ли?
Ну вот я и писал выше, что с массивами неудобно.
Но мне, например, такая штука нужна для конфигов, а не для динамики
Но мне, например, такая штука нужна для конфигов, а не для динамики
AK
Для статики ничего особенного неудобного нет, кроме того факта, что если массивы используются активно, то доступ по ключу в хеше медленнее конечно доступа к элементу массива
AK
Собственно, из чего возникает проблема и мысль её как-то решить:
$config{'sessions'}{'cookie'}{'default_ttl'}
Это прямо реальный пример для веб-приложения.
Я не хочу сохранять это в переменной только по той причине, что поиск по 3-м хешам - дико медленная операция.
$config{'sessions'}{'cookie'}{'default_ttl'}
Это прямо реальный пример для веб-приложения.
Я не хочу сохранять это в переменной только по той причине, что поиск по 3-м хешам - дико медленная операция.
IB
> что поиск по 3-м хешам - дико медленная операция.
IB
это очень смешной тезис
AK
Как минимум мне придётся для переменной, в которую я сохраняю, делать какое-то имя, которое бы указывало на то, что значение приехало из конфига, а не от пользователя или ещё откуда-либо.
AK
это очень смешной тезис
Ну ок, мне это и печатать тоже лень.
Кстати, дополню на самом деле список преимуществ: подход типа json.path позволяет одному значению структуры легко сослаться на другое значение.
Условно, если я хочу, чтобы alias был таким же, как uid , я могу просто сказать: alias: {{$this.uid}} . Семантика $this реализуется достаточно легко (хотя и не универсальна) и всё, что нужно для доступа к элементу, на который ссылаются - это сформировать строку из 2х частей и запросить её в хеше
Кстати, дополню на самом деле список преимуществ: подход типа json.path позволяет одному значению структуры легко сослаться на другое значение.
Условно, если я хочу, чтобы alias был таким же, как uid , я могу просто сказать: alias: {{$this.uid}} . Семантика $this реализуется достаточно легко (хотя и не универсальна) и всё, что нужно для доступа к элементу, на который ссылаются - это сформировать строку из 2х частей и запросить её в хеше
SZ
это очень смешной тезис
++
AK
А что именно смешного?
AK
Если применительно к perl'у - наверное, можно сказать, что он сам по себе медленный, поэтому накладные расходы на хеш мизерные, но если универсально судить - поиск в 3-х хешах для программы на C - это дешёвая операция?
AK
Кстати, + ещё преимущество: для json.path можно использовать вообще не хеши, а максимально быстрые trie.
SZ
А что именно смешного?
Ща
SZ
У меня совещание, я приду чуть позже
SZ
В общем, вдруг уже есть?
Вряд ли можно, но думаю нетрудно написать
IB
> поиск в 3-х хешах для программы на C - это дешёвая операция?
Это очень абстрактый вопрос. Мой ответ — "это зависит от множества факторов". Как хеш реализован. Сколько там элементов. Что считаем дешевой а что дорогой операцией. В разных ситацию одно и то же время работы может быть приемлемым, а может совершенно не подходить. Зависит.
Это очень абстрактый вопрос. Мой ответ — "это зависит от множества факторов". Как хеш реализован. Сколько там элементов. Что считаем дешевой а что дорогой операцией. В разных ситацию одно и то же время работы может быть приемлемым, а может совершенно не подходить. Зависит.
SZ
Товарищи! Нет ли возможности какой-то парсить JSON и YAML-конфиги в хеш, ключами которого являются конкатенированные последовательности наподобие JSON.Path?
Например,
{"data": {"creds": {"login": "jaja", "password": "nein"}}}
мог бы распарситься в хеш:
{
'data.creds.login' => 'jaja',
'data.creds.password' => 'nein'
}
Какие проблемы это решает?
1) Повышает быстродействие: доступ к $config{'data'}{'creds'}{'login'} в общем случае медленнее доступа к $config{'data.creds.login'}
2) Обеспечивает простой доступ к элементу по описанию пути к нему: используем реальный JSON.Path И не вынуждены рекурсивно обходить хеш в хеше в массиве в хеше для поиска какого-нибудь data.users.0.creds.password
3) Позволяет легко делать и загружать дампы подобных структур в виде набора пар ключ-значение
Какие проблемы создаёт:
1) Накладывает ограничения на имена полей: не позволяет использовать разделитель внутри имён полей. Например, нельзя назвать поле "foo.bar", если разделитель - точка.
2) Если много вложенных массивов и мало хешей - невыгодно с т.з. производительности
2) Длинные ключи в хеше
Например,
{"data": {"creds": {"login": "jaja", "password": "nein"}}}
мог бы распарситься в хеш:
{
'data.creds.login' => 'jaja',
'data.creds.password' => 'nein'
}
Какие проблемы это решает?
1) Повышает быстродействие: доступ к $config{'data'}{'creds'}{'login'} в общем случае медленнее доступа к $config{'data.creds.login'}
2) Обеспечивает простой доступ к элементу по описанию пути к нему: используем реальный JSON.Path И не вынуждены рекурсивно обходить хеш в хеше в массиве в хеше для поиска какого-нибудь data.users.0.creds.password
3) Позволяет легко делать и загружать дампы подобных структур в виде набора пар ключ-значение
Какие проблемы создаёт:
1) Накладывает ограничения на имена полей: не позволяет использовать разделитель внутри имён полей. Например, нельзя назвать поле "foo.bar", если разделитель - точка.
2) Если много вложенных массивов и мало хешей - невыгодно с т.з. производительности
2) Длинные ключи в хеше
ЗЫ в общем случае доступ a->b->c быстрее, чем a но с бо́льшим числом ключей
IB
А что именно смешного?
Смешное то что нужно оптимизировать только то что реально болит. Сначала нужно проверить с помощью Devel::NYTProf где есть проблемы и чинить то что даст наибольший выигрыш (и только в том случае если действительно есть проблема со скоростю работы — если скрипт запускается один раз в день, то пофигу сколько он будет работать, 300 миллисекунд или 15 минут)