В детстве на ZX Spectrum как то по учебнику делал эффект таяния экрана и в качестве набора случайных чисел использовал первые 16 килобайт памяти где хранилась прошивка.
Я надеюсь авторы учли, что полноразмерный девайс будет весить не в 3, а примерно в 9 раз тяжелее прототипа (если просто пропорционально увеличить все размеры). Соответственно возрастут и требования к двигателям и запасу топлива/батарей
А с VolatileImage не пробовали работать? Можно предварительно загрузить все спрайты в видео память. Тогда отрисовка и трансформации будут производиться очень быстро. Правда придется следить, за валидностью спрайтов и регенерировать их, если вилюха решит память почистить
Как дорожник по образованию замечу, что длинных прямых не делают специально, чтобы не гоняли, и чтобы не засыпали за рулем.
Да и такие факторы как геология, заносимость снегом, гидро-геология, близость населенных пунктов тоже нехило влияют на план трассы.
Нельзя просто так взять и проложить дорогу по прямой.
Ну в моем примере разница между кодом котрый я привел, и нормальным кодом котрый для этих целей пишут с школе на уроке информатики минут 10.
А затраты на профилирование?
Я хотел привсти пример, premature pessimization, когда есть очевидный алгоритм с линейной сложностью и не занимающий дополнитнльной памяти, не требующий супер-усилий.
Даже если типичный массив всего 100 элементов он может просматриваться тысячи раз. В таком очевидном случае лучше сразу написать оптимально.
А вот излишней premature оптимизацией было бы городить какое-нибудь кэширование, мол если в этом массиве уже искали максимум, а массив не изменялся, то давайте возьмем из кэша. Даже если бы это потенциально могло дать постоянное время поиска.
Посмотрите мой пример чуть выше про поиск максимального элемента в массиве. Уверен, что такое можно устроить и на Андроиде.
А насчет терабайтов и тысяч запросов…
Возможно Яндекс следует стратегии Гугля — в первую очередь ищется сильный инженер, а уже во вторую разработчик для Андроида. Корпоративный стандарт.
Есть пара знакомых в Гугле, которых пересадили с Java на С++ и Python… Ибо по мнению Гугля нормальному инженеру все равно на чем писать.
Ок, пример из реальной жизни. Без всякой архитектуры. Разработчик (индийский) для поиска наибольшего элемента в массиве поступил следующим образом — склонировал массив (оригинальный нельзя было изменять), потом отсортировал копию Arrays.sort и взял последний.
Код красивый, три строчки кода, никаких ветвлений… Красота. Оптимизировать можно потом, правда ведь? И по скорости, и по расходу памяти.
Только вот сроки разработки не резиновые, чтобы тратить их на отлов подобных «перлов»
Не только индусы таким грешат, наши тоже. Вот и приходится проверять на собеседованиях, и сортировки, и обход дерева, и вские виды поиска.
Смотря о каком уровне оптимизации мы говорим. Об оптимизации уровня кода, или об оптимизации уровня дизайна. Второе может быть многократно дороже, если вообще возможно. Многие знают про «don't optimize prematurely», и с гордостью говрят об этом на собеседованиях, но обычно забывают про менее известное «don't pessimize prematurely».
1. Вычислительные мощности ограничены (не у всех же 4-х ядерные монстры за штуку баксов). Сначала программисты говорят, зачем знать логику и алгоритмы, а потом пользователи удивляются, чего это у них приложение тормозит и страницы листаются по одной в секунду.
2. Очень многие современные приложения — всего лишь фронт-энд к серверу. Сервер будет явно не рад, получить десять запросов, там где можно обойтись одним. Для приложения у которого 1000 скачиваний может и ничего, но приложения яндекса скачиваются миллионами…
Похоже на гугловскую задачу. :-) Вы точно не у меня собеседовались.
Я попроще спрашиваю. Выбрать k наибольших из N. При этом N >> k
Задача кажется простой до безобразия. Но при N измеряющихся миллионами… можно очень сильно сэкономить по времени, особенно если k и N отличаются на порядки
Сам в виде хобби обучаю нейросети генетическими алгоритмами. Стохастика при творческом подходе позволяет выскакивать из локальных минимумов.
А сколько физического времени занимает у вас 500 эпох?
Генератор имен реальных/фентезийных. Умеет дописывать имена в выбранном стиле, если ввести несколько первых букв.
Ничего не меняется
Да и такие факторы как геология, заносимость снегом, гидро-геология, близость населенных пунктов тоже нехило влияют на план трассы.
Нельзя просто так взять и проложить дорогу по прямой.
А затраты на профилирование?
Я хотел привсти пример, premature pessimization, когда есть очевидный алгоритм с линейной сложностью и не занимающий дополнитнльной памяти, не требующий супер-усилий.
Даже если типичный массив всего 100 элементов он может просматриваться тысячи раз. В таком очевидном случае лучше сразу написать оптимально.
А вот излишней premature оптимизацией было бы городить какое-нибудь кэширование, мол если в этом массиве уже искали максимум, а массив не изменялся, то давайте возьмем из кэша. Даже если бы это потенциально могло дать постоянное время поиска.
А насчет терабайтов и тысяч запросов…
Возможно Яндекс следует стратегии Гугля — в первую очередь ищется сильный инженер, а уже во вторую разработчик для Андроида. Корпоративный стандарт.
Есть пара знакомых в Гугле, которых пересадили с Java на С++ и Python… Ибо по мнению Гугля нормальному инженеру все равно на чем писать.
Код красивый, три строчки кода, никаких ветвлений… Красота. Оптимизировать можно потом, правда ведь? И по скорости, и по расходу памяти.
Только вот сроки разработки не резиновые, чтобы тратить их на отлов подобных «перлов»
Не только индусы таким грешат, наши тоже. Вот и приходится проверять на собеседованиях, и сортировки, и обход дерева, и вские виды поиска.
2. Очень многие современные приложения — всего лишь фронт-энд к серверу. Сервер будет явно не рад, получить десять запросов, там где можно обойтись одним. Для приложения у которого 1000 скачиваний может и ничего, но приложения яндекса скачиваются миллионами…
Я попроще спрашиваю. Выбрать k наибольших из N. При этом N >> k
Задача кажется простой до безобразия. Но при N измеряющихся миллионами… можно очень сильно сэкономить по времени, особенно если k и N отличаются на порядки