2. С каких это пор лучше грузить картинки в несколько потоков?
Балласт есть у любого формата. У html — внутри html, в заголовках http. У js — в запускающей html-странице. У png, jpg — в заголовках. У swf он тоже есть, но никак не в несколько килобайт(потому что www.simppa.fi/demo/vinyl4k/ — 4052 байта), точнее надо мерить. (Я на днях как раз собираюсь запилить минимальную демку, посмотрим...)
Кроме того, говоря об отображении интерфейса, я думаю, почти весь этот флеш приходится на рекламные баннеры, там интерфейса нет.
У вас либо глубокие проблемы с проектированием, либо глубокие проблемы с чтением документации. По моему опыту — скорее второе, причем в системе разбирается лучше всех именно тот человек, который везде кладет ссылки.
Так, почитал подробнее про рута под Андроидом. Рут именно тот, какого я и ожидал от линукс-бэйзд системы, но, как выяснилось, я пользуюсь не базовым функционалом, а набором софта, установленного поверх(я-то думал, что это стандартный системный софт). Видимо, все связано с тем, что я покупал его с уже установленным апдейтом до 2.2. (Значит, я сделал правильный выбор, покупая телефон, на котором все эти махинации заранее совершены, и нежелая заниматься этим самому.)
Orange San Francisco, так же известный как ZTE Blade. (Оно вообще слабохиленькое, покупалось как замена эмулятору, но времени покопаться в Андроиде все нет, и оно перекочевало в мой карман и активно исопльзуется для чтения почты теперь.)
А относительно фреймворков, я написал же, «Тут все зависит от окружениях. На многих виртуальных машинах регэкспы легко переплевывают всякие хитрые махинации с байтами.»
Разницы между компиляцией регэкспа и использованиеем, и реплэйс олл — 1 строка. В первом случае четко прослеживается логика, во втором нет (Для меня replaceAll неочевидна, я от такой функции ожидаю строковую замену, а не регэксповую.).
Наверное, это в некоторой степени вопрос предпочтений, но если код не для тулзы на 2 раза, использование регэкспов без прекомпиляции в циклах считал и буду считать ошибкой. Конечно, не всегда это сильно влияет на скорость исоплнения, но не вижу никаких причин искусственно замедлять софт, пусть даже и лишь на десяток миллисекунд(которые, кстати, из-за количества запусков могут вылиться в достаточно продолжительные промежутки времени). В этом вопросе я заодно с пользователями — чем быстрее работает софт, тем лучше.
Опять-же, лучше надо читать.
Это обычное такое бутылочное горлышка, и обычная такая оптимизация. Если речь идет о скорости — скорее всего таких встретится далеко не одно.
Если же говорить о конкретно этой проблеме:
Изначальный вариант был коряв в том плане, что регэксп не компилировался. Это — большая и очевидная ошибка программиста.
Второй момент, на который стоит обратить внимание — то, что мы делаем не обычную замену, а замену на подстроку, которая по размерам не превосходит заменяемой подстроки. Казалось бы, разница не велика, но это позволяет хорошо экономить на преаллокации(А если можно работать деструктивно, то мы можем вообще не преаллоцировать, а переписывать инплэйс.). На мой взгляд, в библиотеки стоило бы ввести стандартные функции замены на меньшую подстроку и замены на пустую строку. Это хорошая оптимизация, но для каждого конкретного случая писать такую функцию — немного оверкилл. Так что, как я уже сказал, я считаю, что такие должны быть в стандартных библиотеках.
Ну и последнее — это, собственно, использование регэкспов. Тут все зависит от окружениях. На многих виртуальных машинах регэкспы легко переплевывают всякие хитрые махинации с байтами. Если говорить конкретно о C++, то регэксп не получает никаких преимуществ по сравнению с вашим собственном кодом и врядли найдутся случаи, где такие простые обработки строк регэкспами будут быстрее, чем самописный вариант(даже в случае достаточно кривых рук). Но тут, опять-же, стоит подумать о том, что простых обработок строк не так уж и много, так что по-хорошему это пишется один раз, кладется в библиотеку и потом радостно используется.
На самом деле, for тоже можно написать в таком стиле:
for ( int i = v.size ( ); i -->0; )
Да, одна строка лучше двух, и инкапсуляция это хорошо, но когда я вижу эти идиотские точки с запятой — мне резко перестает нравиться for-версия(сейчас я про последний символ, висящий, хотя не нравятся мне они все внутри for).
Относительно байткода — думаю, результат просто обязан быть идентичным.
А вообще, у меня это осознанная необходимость — я в основном пишу на haXe, а в нем for работает только с итераторами. Канонически, это надо писать как for(i in 0...v.size()) (Да-да, тип i инферится), где 0...v.size() — сахарный конструктор итератора. Плюс — такой итератор в цикле развернется. Минус — только от меньшего к большему. Так что если хочется выжать немного больше производительности — приходится спускаться к while в любом случае. Но я начал находить в этом особый кайф — while автоматически отмечает оптимизированные места.
И, да, надо уже добавить возможность прохода от большего к меньшему. На самом деле, если я этим займусь, то итоговая версия будет идеальна, на мой взгляд, for(i in v.size()...0) в идеальную по скорости конструкцию.
«Ну это так, на пару лет. Будет круто, потом наверное чуть-чуть охладеем, начнутся некоторые проблемы. Через годик по-быстрому разведемся — и все ок, можно идти дальше.»
Мне кажется, это охуительный взгляд, который реально помогает быть счастливее и ответственнее.
И не будет потом мыслей про себя «как же она меня достала», не будет «но куда же я уйду от детей», не будет «не хочу домой, лучше посижу на работе, а потом нажрусь в кабаке»…
Балласт есть у любого формата. У html — внутри html, в заголовках http. У js — в запускающей html-странице. У png, jpg — в заголовках. У swf он тоже есть, но никак не в несколько килобайт(потому что www.simppa.fi/demo/vinyl4k/ — 4052 байта), точнее надо мерить. (Я на днях как раз собираюсь запилить минимальную демку, посмотрим...)
Кроме того, говоря об отображении интерфейса, я думаю, почти весь этот флеш приходится на рекламные баннеры, там интерфейса нет.
Orange San Francisco, так же известный как ZTE Blade. (Оно вообще слабохиленькое, покупалось как замена эмулятору, но времени покопаться в Андроиде все нет, и оно перекочевало в мой карман и активно исопльзуется для чтения почты теперь.)
Наверное, это в некоторой степени вопрос предпочтений, но если код не для тулзы на 2 раза, использование регэкспов без прекомпиляции в циклах считал и буду считать ошибкой. Конечно, не всегда это сильно влияет на скорость исоплнения, но не вижу никаких причин искусственно замедлять софт, пусть даже и лишь на десяток миллисекунд(которые, кстати, из-за количества запусков могут вылиться в достаточно продолжительные промежутки времени). В этом вопросе я заодно с пользователями — чем быстрее работает софт, тем лучше.
Подтвикать коэффициенты, поменять плюс на минус, подогнать гуй за пол-минуты, и через 3 секунды посмотреть на результат — это очень удобно.
Это обычное такое бутылочное горлышка, и обычная такая оптимизация. Если речь идет о скорости — скорее всего таких встретится далеко не одно.
Если же говорить о конкретно этой проблеме:
Изначальный вариант был коряв в том плане, что регэксп не компилировался. Это — большая и очевидная ошибка программиста.
Второй момент, на который стоит обратить внимание — то, что мы делаем не обычную замену, а замену на подстроку, которая по размерам не превосходит заменяемой подстроки. Казалось бы, разница не велика, но это позволяет хорошо экономить на преаллокации(А если можно работать деструктивно, то мы можем вообще не преаллоцировать, а переписывать инплэйс.). На мой взгляд, в библиотеки стоило бы ввести стандартные функции замены на меньшую подстроку и замены на пустую строку. Это хорошая оптимизация, но для каждого конкретного случая писать такую функцию — немного оверкилл. Так что, как я уже сказал, я считаю, что такие должны быть в стандартных библиотеках.
Ну и последнее — это, собственно, использование регэкспов. Тут все зависит от окружениях. На многих виртуальных машинах регэкспы легко переплевывают всякие хитрые махинации с байтами. Если говорить конкретно о C++, то регэксп не получает никаких преимуществ по сравнению с вашим собственном кодом и врядли найдутся случаи, где такие простые обработки строк регэкспами будут быстрее, чем самописный вариант(даже в случае достаточно кривых рук). Но тут, опять-же, стоит подумать о том, что простых обработок строк не так уж и много, так что по-хорошему это пишется один раз, кладется в библиотеку и потом радостно используется.
for ( int i = v.size ( ); i -->0; )
Да, одна строка лучше двух, и инкапсуляция это хорошо, но когда я вижу эти идиотские точки с запятой — мне резко перестает нравиться for-версия(сейчас я про последний символ, висящий, хотя не нравятся мне они все внутри for).
Относительно байткода — думаю, результат просто обязан быть идентичным.
А вообще, у меня это осознанная необходимость — я в основном пишу на haXe, а в нем for работает только с итераторами. Канонически, это надо писать как for(i in 0...v.size()) (Да-да, тип i инферится), где 0...v.size() — сахарный конструктор итератора. Плюс — такой итератор в цикле развернется. Минус — только от меньшего к большему. Так что если хочется выжать немного больше производительности — приходится спускаться к while в любом случае. Но я начал находить в этом особый кайф — while автоматически отмечает оптимизированные места.
И, да, надо уже добавить возможность прохода от большего к меньшему. На самом деле, если я этим займусь, то итоговая версия будет идеальна, на мой взгляд, for(i in v.size()...0) в идеальную по скорости конструкцию.
Мне кажется, это охуительный взгляд, который реально помогает быть счастливее и ответственнее.
И не будет потом мыслей про себя «как же она меня достала», не будет «но куда же я уйду от детей», не будет «не хочу домой, лучше посижу на работе, а потом нажрусь в кабаке»…
Эта проблема применима даже к ассемблеру.
int i = v.size();
while(i --> 0){
…
}