SM
А в чем профит? Так же копим стек. Или я чего не понимаю?
Size: a a a
2020 March 22
АП
А в чем профит? Так же копим стек. Или я чего не понимаю?
В одном случае стек наш, в другом - стек вызовов со своими ограничениями
SM
Кстати. Теоретический вопрос. Есть некоторый объект с большой вложенностью. Нужно найти и заменить значение ключа, который где-то там. Ключ уникален.
Быстрее ли будет перевести объект в текст, найти ключ, а значение заменить через регулярную?
Быстрее ли будет перевести объект в текст, найти ключ, а значение заменить через регулярную?
SM
В одном случае стек наш, в другом - стек вызовов со своими ограничениями
Это быстрее?
АП
Это быстрее?
Это гарантия того, что переполнение не наступит так же быстро
SM
Это гарантия того, что переполнение не наступит так же быстро
Понял
АП
Кстати. Теоретический вопрос. Есть некоторый объект с большой вложенностью. Нужно найти и заменить значение ключа, который где-то там. Ключ уникален.
Быстрее ли будет перевести объект в текст, найти ключ, а значение заменить через регулярную?
Быстрее ли будет перевести объект в текст, найти ключ, а значение заменить через регулярную?
Перевод объекта в текст это уже подход по всем его полям
А потом ещё проход по тексту с поиском нужного
А потом ещё проход по тексту с поиском нужного
SM
Перевод объекта в текст это уже подход по всем его полям
А потом ещё проход по тексту с поиском нужного
А потом ещё проход по тексту с поиском нужного
Любое действие это проход) вопрос в скорости
SM
У меня есть совершенно идиотская задача, просто)
SM
Есть система, где каждая запись содержит ещё и метаданные. С тегами полей записи. Так вот, чтобы узнать где нужное тебе поле, сначала надо пройти по метаданным ю, найти тег и из него взять uid, а потом найти по нему поле.
АП
Любое действие это проход) вопрос в скорости
Но не по всему объекту
Если искомое значение второе - остальные проходить не нужно
Да даже если оно последнее, не нужно выделять память под текст (причём это может быть множеством действий, в том числе с переносом памяти из одной области в другую), делать строку из объекта, проходить по этой строке
В общем, с точки зрения сложности алгоритма ответ очевиден
Если искомое значение второе - остальные проходить не нужно
Да даже если оно последнее, не нужно выделять память под текст (причём это может быть множеством действий, в том числе с переносом памяти из одной области в другую), делать строку из объекта, проходить по этой строке
В общем, с точки зрения сложности алгоритма ответ очевиден
SM
Но не по всему объекту
Если искомое значение второе - остальные проходить не нужно
Да даже если оно последнее, не нужно выделять память под текст (причём это может быть множеством действий, в том числе с переносом памяти из одной области в другую), делать строку из объекта, проходить по этой строке
В общем, с точки зрения сложности алгоритма ответ очевиден
Если искомое значение второе - остальные проходить не нужно
Да даже если оно последнее, не нужно выделять память под текст (причём это может быть множеством действий, в том числе с переносом памяти из одной области в другую), делать строку из объекта, проходить по этой строке
В общем, с точки зрения сложности алгоритма ответ очевиден
Теперь вижу. Ну рекурсией я это уже сделал и откровенно ненавижу архитектора системы)
SM
Только рекурсия не всегда отрабатывает) там nilJs стоит
RB
Нет, сразу ты написал,что обход дерева только рекурсией возможен (https://t.me/nodejs_ru/475352)
Так как мне гораздо чаще приходилось видеть варианты без рекурсии, и даже конкретно - чаще обход в ширину, я и отреагировал на твои слова
Обход в ширину пишется на js элементарно, я уверен что ты и сам напишешь
Так как мне гораздо чаще приходилось видеть варианты без рекурсии, и даже конкретно - чаще обход в ширину, я и отреагировал на твои слова
Обход в ширину пишется на js элементарно, я уверен что ты и сам напишешь
Да, перечитал. Ты прав. После этого только уточнил что хотелось бы увидеть код именно на JS. Я видел решения в основном на C/C++, и обход в ширину (который со стеком) и ещё какой-то, где каждому узлу надо назначать ещё и ссылку на родителя и следующий/предыдущий узлы (и это довольно громоздкий код получается для обхода).
RB
Мне кажется рекурсия тут именно и проще и быстрее (наверное) и никаких ограничений (вероятность того что превысим стэк в 12 тыс. уровней крайне мала).
АП
Мне кажется рекурсия тут именно и проще и быстрее (наверное) и никаких ограничений (вероятность того что превысим стэк в 12 тыс. уровней крайне мала).
RB
Да это я сразу написал (для проверки бенчмарка). Только у меня без left/right.
АП
Да это я сразу написал (для проверки бенчмарка). Только у меня без left/right.
Я про поиск в ширину. Код на js, без рекурсии, и вроде простой
RB
Я про поиск в ширину. Код на js, без рекурсии, и вроде простой
Я понял о чём ты. Я написал почти такую же функцию, но не понял зачем ему left/right. Статью ещё не читал.
RB
Я про поиск в ширину. Код на js, без рекурсии, и вроде простой