Итак, у нас был случай, когда у нас был бы некоторый JSON, где key - id (int), а значение - строка. Но мы заметили, что большую часть времени мы ищем идентификатор на основе строки, поэтому мы решили отменить его и сделать строку ключом, а значение - идентификатором. Потому что вместо того, чтобы проходить через каждый элемент и сравнивать значения, мы могли бы просто сделать var id = storage[text];
. Ниже приведены примеры того, что мы сделали.Есть ли ограничение на длину ключа (строки) в объекте JS?
Вот пример старой реализации:
var storage = {
0 : null,
1 : "Hello",
2 : "world!",
3 : "How are you?"
}
Вот пример реализации новой:
var storage = {
"null" : 0,
"Hello" : 1,
"world!" : 2,
"How are you?" : 3
}
Я понимаю, что теперь строка является ключом, и это нормально, чтобы получить то же самое id для одних и тех же строк. Но так как теперь строка может быть потенциально довольно огромной (небольшой шанс, но, вероятно, максимальный 1 КБ на строку), есть ли ограничение по длине JS или Android-веб-браузер на клавиши объекта?
А также имеет ли эта реализация недостатки? Я пока не заметил никаких проблем, но вы никогда не знаете.
Любая * продолжительность исполнения * для длинных клавиш в современных браузерах? –
@AhmedFasih Я не тестировал его, поэтому не знаю точно. Если есть штраф за производительность, я бы предположил, что это связано с сравнением длинных строк. Я был бы удивлен, если на практике возникнут проблемы, которые важны на практике - если только ключи не являются _huge_ и многочисленными, и вы начинаете сталкиваться с ограничениями памяти, например. на мобильном телефоне. – hashchange
Спецификация ES7 указывает [предел 2^53 - 1 из «элементов»] (http://www.ecma-international.org/ecma-262/7.0/index.html#sec-ecmascript-language-types-string -тип). Но я думаю, что он ограничен максимальным размером кучи – mems