SZ
Если применительно к perl'у - наверное, можно сказать, что он сам по себе медленный, поэтому накладные расходы на хеш мизерные, но если универсально судить - поиск в 3-х хешах для программы на C - это дешёвая операция?
Да
Size: a a a
2021 January 11
SZ
Я как раз работаю в проекте, который на этом очень много денег сделал. И раньше я думал, что это слишком большой оверхед
b
Товарищи! Нет ли возможности какой-то парсить 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) Длинные ключи в хеше
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) Длинные ключи в хеше
SZ
Сначала читаешь json/yaml имеющимися модулями, потом флатишь полученный nested hash и пользуешься
AK
Надо ключи вложенных структур как последовательность префиксных деревьев замутить. Только не на Perl
SZ
Надо ключи вложенных структур как последовательность префиксных деревьев замутить. Только не на Perl
Ну как бы зачем?
SZ
Это всё равно будет медленно работать
AK
Для ограниченного набора слов из ... лексиконов (слов, характерных для проблемной области) ветвлений при поиске очень мало, а иногда их и вовсе нет.
AK
Поиск по trie столько зависит от количества ветвлений по пути
AK
Если, например, ключ конфига на уровне N, начинающийся на букву "c" всего один - поиск в префиксном дереве будет намного быстрее, чем в хеше.
SZ
Ты меня не понял
AK
Вероятность наличия в конфиге ключей в духе
code, cool, coalesce
- ещё ниже, вероятность наличия множества таких случаев - вообще исчезающе мала
code, cool, coalesce
- ещё ниже, вероятность наличия множества таких случаев - вообще исчезающе мала
SZ
Вероятность наличия в конфиге ключей в духе
code, cool, coalesce
- ещё ниже, вероятность наличия множества таких случаев - вообще исчезающе мала
code, cool, coalesce
- ещё ниже, вероятность наличия множества таких случаев - вообще исчезающе мала
SZ
Для перла это ненужно
SZ
Потому что оно всё равно будет через перлокод вызываться на стыке перла и си
AK
Ты меня не понял
С учётом того, что для расчёта индекса в хеше используется неконтролируемый пользователем алгоритм и с вероятностью 99% этот алгоритм использует все символы ключа - эффективная реализация trie для "лексиконов" будет быстрее хеширования
VG
Товарищи! Нет ли возможности какой-то парсить 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) Длинные ключи в хеше
мне кажется, тебе на самом деле нужен Data::DPath
AP
С учётом того, что для расчёта индекса в хеше используется неконтролируемый пользователем алгоритм и с вероятностью 99% этот алгоритм использует все символы ключа - эффективная реализация trie для "лексиконов" будет быстрее хеширования
сначала забенчмаркай этот кейс на своих данных. а то може оказаться, что твоя собака не на то дерево лает
AK
сначала забенчмаркай этот кейс на своих данных. а то може оказаться, что твоя собака не на то дерево лает
Мне интереснее общее решение под множество кейсов определенного типа. В данном случае под всякие конфиги в xml, json, yaml , ini