SZ
вот хороший вопрос... я более чем уверен, что у телеги mysql, а завезли ли туда рекурсивные запросы / для деревьев, не знаю
Я более чем уверен, что у телеги не rdbms
Size: a a a
2020 December 23
VG
Я более чем уверен, что у телеги не rdbms
ты слишком хорошего об олимпиадниках мнения =)
SZ
А в перле есть разница, искать в десяти хешах со ста значениями каждый, или в одном с тысячью?
Типа,
$h_a = {a_1=>1, a_2=>2};
$h_b = {b_1=>1, b_2=>2};
против
$h_z = {a_1=>1, a_2=>2, b_1=>1, b_2=>2};
Математически, разницы быть не должно.
В перле же вообще всё-всё на хешах внутри, правильно? Как и в JS.
Типа,
$h_a = {a_1=>1, a_2=>2};
$h_b = {b_1=>1, b_2=>2};
против
$h_z = {a_1=>1, a_2=>2, b_1=>1, b_2=>2};
Математически, разницы быть не должно.
В перле же вообще всё-всё на хешах внутри, правильно? Как и в JS.
В чём суть вопроса? Я не понимаю твой синтаксис
SZ
А в перле есть разница, искать в десяти хешах со ста значениями каждый, или в одном с тысячью?
Типа,
$h_a = {a_1=>1, a_2=>2};
$h_b = {b_1=>1, b_2=>2};
против
$h_z = {a_1=>1, a_2=>2, b_1=>1, b_2=>2};
Математически, разницы быть не должно.
В перле же вообще всё-всё на хешах внутри, правильно? Как и в JS.
Типа,
$h_a = {a_1=>1, a_2=>2};
$h_b = {b_1=>1, b_2=>2};
против
$h_z = {a_1=>1, a_2=>2, b_1=>1, b_2=>2};
Математически, разницы быть не должно.
В перле же вообще всё-всё на хешах внутри, правильно? Как и в JS.
Есть разница, да
SZ
А в перле есть разница, искать в десяти хешах со ста значениями каждый, или в одном с тысячью?
Типа,
$h_a = {a_1=>1, a_2=>2};
$h_b = {b_1=>1, b_2=>2};
против
$h_z = {a_1=>1, a_2=>2, b_1=>1, b_2=>2};
Математически, разницы быть не должно.
В перле же вообще всё-всё на хешах внутри, правильно? Как и в JS.
Типа,
$h_a = {a_1=>1, a_2=>2};
$h_b = {b_1=>1, b_2=>2};
против
$h_z = {a_1=>1, a_2=>2, b_1=>1, b_2=>2};
Математически, разницы быть не должно.
В перле же вообще всё-всё на хешах внутри, правильно? Как и в JS.
Математически разница также есть (и должна быть, да)
SZ
там в доке есть, как получить стату по заполнению корзин хэша
Хехе, просто взять от хеша pv
АК
Математически разница также есть (и должна быть, да)
Если хеш асимптотически O(1), то не важно, один в нём элемент, или десять тысяч.
SP
Unable to download perl dependency modules in cpan
SP
Please suggest correct
SP
Site
R
Cpan is the best for perl dependency
R
May be ur organization is blocked cpan
SZ
Если хеш асимптотически O(1), то не важно, один в нём элемент, или десять тысяч.
Как раз всё не так
АК
А что там, логарифм?
SZ
Sudhakar P
Please suggest correct
Search for any cpan mirrors in your country
SZ
А что там, логарифм?
Там нелинейное пространство и разная вероятность коллизий. В зависимости от числа элементов в том числе, потому что разное число бакетов
SP
May be ur organization is blocked cpan
No It is opening
АК
Там нелинейное пространство и разная вероятность коллизий. В зависимости от числа элементов в том числе, потому что разное число бакетов
Мне в JS странно то, что «объект» – это и объект с полями, и хеш-таблица.
Например, когда я использую объект именно как объект – полей у него будет немного, но они окажутся разных типов.
А когда я использую объект как хеш-таблицу – я собираюсь добавлять в неё очень много (и возможно, удалять), но скорее всего одинаковых типов.
Почему в явном виде через синтаксис нельзя обозначить намерения? Очевидно что там должна быть разная оптимизация.
А так, получается это чисто JIT должен угадывать, что ж я с хешом собрался делать.
В перле вроде точно так же (правда чуть лучше, поскольку у хешей нет неявных полей, и они всегда «чистые»).
Например, когда я использую объект именно как объект – полей у него будет немного, но они окажутся разных типов.
А когда я использую объект как хеш-таблицу – я собираюсь добавлять в неё очень много (и возможно, удалять), но скорее всего одинаковых типов.
Почему в явном виде через синтаксис нельзя обозначить намерения? Очевидно что там должна быть разная оптимизация.
А так, получается это чисто JIT должен угадывать, что ж я с хешом собрался делать.
В перле вроде точно так же (правда чуть лучше, поскольку у хешей нет неявных полей, и они всегда «чистые»).
АК
Как будто подразумевается, что «хеши у нас работают так хорошо, что аж не важно, как и сколько ты собираешься использовать хеши/объекты, они работают максимально эффективно».
АК
Я читал, как движок V8 оптимизирует поля объектов для индексации: он создаёт «схему» объекта (например {x:1} – схема «x»), которая превращается в другие схемы по мере добавления ключей (то есть {x:1, y:2} будет переход в схему x,y).
Поэтому объекты работают быстро, если на вход и выход функций попадают объекты с одинаковыми схемами.
Но если начать воротить хранилище рандомных ключей – это ж всё лишние действия будут…
Поэтому объекты работают быстро, если на вход и выход функций попадают объекты с одинаковыми схемами.
Но если начать воротить хранилище рандомных ключей – это ж всё лишние действия будут…