Даже если проверка на каждый элемент занимает час, оценка времени будет O(n).
ок, допустим требуется найти в массиве чисел arr индекс i такого элемента, что someFunc(arr[j], arr[i]) === true, для всех j < i. Попробуй сделать за O(N), понимающий ты наш.
Получение индекса в массиве тоже может занять куда более O(n), если например по каждому элементу делается сложная проверка. Так что нет никакого смысла в оценку операции вставки добавлять ещё и поиск.
GlazOtca, здесь есть всего 3 вызова хука - два useState(..) и один useEffect.(..) Они все безусловно вызываются на верхнем уровне компонента App.
Поинт про внешнюю функцию не понял.
Да, впечатляет. Интересно, почему буфер не загружается синхронно. Хотя вот только сейчас подумал: тебе и не нужен буфер, а нужна именно строка, чтобы в ней сделать поправки! Так что да, TextEncoder в помощь, всё правильно.
Вообще, удивительно, что в браузере до сих пор нет нормального встроенного средства кодирования бинарника в base64, как в node.js. "Строковый" параметр для btoa - какое-то средневековье.
Сергей Соколов, ну тогда, по идее, fetch должен режектиться сам.
вызовы SDK, наверно, не умеют принимать abortController? тогда можно обернуть последний в промис (который будет режектиться по аборту), и этот промис присовокуплять, например, через Promise.race к вызовам SDK, либо просто написать для этих вызовов универсальную обертку с конструктором промиса, в котором отслеживать abortController, и работать с SDK уже через эту обертку.
Тогда не придется везде втыкать проверку - аборт в abortController вызовет reject в любой текущей асинхронной операции, и прервется вся цепочка.
Евгений Журов, для findIndex достаточно проверить на равенство. Потому что он тупо обходит массив и проверяет каждый элемент. А для бинарного поиска не обойтись без сравнения "меньше". В этом ключевая разница.
Полагаю, удобнее будет первый вариант, где колбэк возвращает -1, 0 или 1 (точнее, вместо -1/1 могут быть любые значения меньше/больше нуля). Такой колбэк, например, использует стандартная js функция сортировки массива, это устоявшийся привычный кейс.
да нет, не любое. Изображения с другого сервера нарисуются на канве, но toBlob после этого уже не сработает. Там тот же принцип - если нельзя скачать аяксом, то и нельзя забрать с канвы.
Anonymous Penguin, нет, реверсить не придется, я ведь предлагаю сделать цикл в обратном направлении. unshift в цикле нежелателен - приводит к О(N^2) на ровном месте, это может сказаться на скорости, если итераций много
А что за либа? Почти наверняка она это делает через canvas, у которого кроме toDataUrl есть ещё toBlob. Я к тому, что стоит присмотреться к документации либы, возможно там есть сохранение в блоб вместо base64.
Владимир Коротенко, эти тонкости тоже могут сильно зависеть от фигур. Если будет какой-то переиспользуемый код, то его лучше вынести в утилсы. Ну или как крайний вариант, для каких-то фигур сделать общие промежуточные подклассы.
ок, допустим требуется найти в массиве чисел arr индекс i такого элемента, что someFunc(arr[j], arr[i]) === true, для всех j < i. Попробуй сделать за O(N), понимающий ты наш.