но при этом будет перерисовываться весь фрейм? а не область изминения? в отличие от Флеш который анализирует и смотрит, какую область фрема отреднерить а какую не трогать и оставить статичной.
Любой exe тоже можно вскрыть, но это могут еденицы и код программы еще не дает шанса все сломать. Также и Флеш игры, получив ресурсы и часть скриптов Флеша еще не значит что вы тутже вмешаетесь в процесс игры. А вот с HTML5 можно прямо в браузере толи IE толи Хром, следить за соурсом и вмешиваться в процесс.
А тем более это важно для Энтерпрайз приложений. Я планировал перейти с Flex на HTML5, из-за шунихи вокруг смерти Флеша и Флекса… но я не рискну написать энтерпрайз приложение на открытом коде, это бред полный.
Да и не каждый Флеш можно декомпилировать. У Адоба давно есть методы защиты Флеша от декомпиляции той о которой вы говорите.
если убрать ложную задачу, общая картина не изменится, проблема в самом core каждой платформы именно в работе с массивами. Также как и подмена $i++ vs ++$i влияет да доли ms в общей картине, но никак не спасает всю ситуацию в целом. 10sec это огромный предел, и PHP тут ничего не спасет, все игры и пути смогут сэкономить % но не общую проблему.
Вижу что безсмыслено чтото доказывать тем кто решил для себя что Флеш зло и ему пора исчезнуть.
Отвечу просто — нету нИ одной задачи на канвасе которую флеш не сможет выполнить да еще с лучшими показателями. В тоже самое время — колосальное кол-во задачь которые HTML5 просто не в состоянии осилить, даже при большом желании.
После долго мучение с портированием Флеш игры в HTML5 я для себя понял одно! Мне проще и быстрее в сотни раз, переписать 2D игру в 3D. И это было проверено на практике. Имея такие фреймворки как Away3d, Alternativa3D, Flare3D и др., уже вчера можно было в очень короткие сроки, реализовать свои идеи.
Потому HTML5 завтра все еще будет предлагать сырую 2D платформу, а Флеш уже вчера предлагал полноценную 3D платформу и не только.
вставив фразу «даст фору флешу»… вы сделали огромную ошибку, и не потому что ибидели флеш, а потому что совершенно незнаете ничего о его достижениях. Видимо вы потдались общей теме Хабры, что Флеш уже похоронили…
Флеш как раз все дальше и дальше отрывается от HTML5 и шансов что HTML5 когдато догонит Флеш, практически никаких. Разве что если Adobe таки решиться его похоронить.
Конкретно на сегодня:
— Флеш уже давно не рендерит весь слой в 2D а только ту часть, в которой происходит изминение что дает максимальный ФПС. Тотже HTML5 все еще делает по старому, каждый фрейм идет рендеринг, и еще не скоро дойдет до этапа аналогичному во Флеш.
— Флеш уже прошел все пути в 2D, и сейчас просто ищет оставшиеся пути его ускорения и оптимизации… больше там развивать нечего для них
— развитие в 3D у Флеша уже дальше чем HTML5 в 2D
По этому «фора Флешу»… вы или неправельно выразились, так нужно было сразу исправить. Или вы далеки от понимания, но решили чисто не забыть кинуть камень в сторону Флеша как это любят делать на Хабре и заработать себе лишнюю карму.
Полностью потдержу!
Все время следил за HTML5, и доси не понимаю всего бреда вокруг него, как и с шумихой вокруг Ajax в свое время, притом что DHTML изначально был, хрен знате сколько лет и прекрасно работал.
Потдавшись шумихе… таки решил попробовать переписать свою игру с Flash на HTML5… в итоге убил тучу времени, но понял что это тупик.!!! Причем тупик по всем фронтам.
1. Код полностью открытый! Нафиг оно мне такое нужно? Я сам взломал много таких игр и быстро пропал интерес… код раскрыт и делай что хочешь.
2. Как мою игру отдать всем в онлайн, на томже Facebook если оргомная аудитория пользователей прекрасно сидит на ХП с IE8 в котором толком ничего не заработает. даже не все framework стабильно работают под IE9.
3. Провел пару тестов на плантшетах с АРМ 6/7 и был в ужосе.
т.е. Чтобы создать свою, допустим соц.игру на HTML5, мне придется убить просто огромное кол-во времени, собирая все покусочкам, оптимизируя безконечно. И писать тучи вариантов игры, чтобы не потерять часть аудитории?
И при всем при этом, вижу почти каждый день, как минусуют любого кто хоть както заступится за Flash. Похоже на хабре это слово стало синонимом с Microsoft, и несет за собой падение кармы упоминувшего в суе. И это IT-шники? :(
почему выбор php+mysql? мне не ведомо. видимо это считается стандартом для многих, да и я восновном вижу в инете большую часть это php или asp.net и в очень редких случаях сервлеты. Видимо потому что линух, потому что бесплатно, и малоли что еще. Базу упомянул только чтобы показать что для аналитики люди не смогли осилить муську, и пошли стандартным путем, все считать на php. Я же сравнил с другой платформой, потому что было чисто любопытно, а что будет там с такой базой? Сам работаю большую часть под SQL Server и там практическинет проблем с размерами и временем, там восновном проблема это как правельно и что из возможного и как применить.
Т.е. еще раз уточню… база тут непричем. Сменить сервер возможности небыло, чтото кординально менять тоже, а спасать нужно было. Вот и была работа в поиске всех больных мест, а чисто для себя сравнения с другими платформами.
Да и не планировали все это специально… для себя они ограничивали в 7 дней и жили с этим. Случайно так вышло, что мне получилось взглянуть и стало инетресно почему так много времени. Попробовал базу, ужасно долго, со своей стороны решить эту проблему не мог не имея доступа к базе. Начал ковырять дальше, увидел обработки огромных масивов на PHP и ужасные тормоза… также начал выяснять и для себя сравнить в других платформах, так как есть другие задачи на asp.net и node.js… что ыбло под рукой и легко перекинуть то по быстром уи проверил. Цифры были очень интересные, решил поделиться… за что нахватал минусов по самые нехочу.
Решение проблемы, было таким:
— в базе оставить только выборку линейную, время в ms
— в php забрать данные с базы удалив все обработки и отдать ввиде data[] массива через ajax клиенту, также время на затраты в ms
— в интерфейсе сидит function переписанная из php в javascript, которая считает всю аналитику за 110ms настороне клиента, тутже создав чарты, плюс возмодность по разнымопциям перерисовать чарты. имея исходники данных а не только суммарные, JS на клиенте может с легкостью за 110ms снова все пересчитать уже по другим группам, хоть по дням, хоть по месяцам, хоть сами группы превернуть… т.е. имеем полностью динамичный клиент, без лишнего обращения к серверу и без потери времени на расчеты.
т.е. в итоге получилось даже лучше, чем есле бы удалось домучать mysql. JavaScript на стороне клиента в чистом виде, позволяет совершать довольно большие расчеты и тутже все отображать не обращаясь к серверной части.
Как помне, то в идеале иметь серверную часть на nodejs+mongodb чисто для приема и выдачи даных клиенту. а все остальное это JS и темплейты, которые один раз загружаются либами, а далее получая только чистые данные от срвера, можно строить и рисовать как душе угодно. Клиент считает все с легкостью, сервер почти полностью разгружен от лишних запросов. gzip доводит размер общения клиента и сервера до смешных пакетов.
вот, можете играться, надеюсь не наделал ошибок перегоняя с SQL в MySQL.
сразу замечу что MS в самой простой и тупой Web редакции, без танцев с бубном войти чрез форточку вместо парадного входа — выполняет суммарный скрипт менее чем за 1 сек, в виртуалке с 1 ядром и 1гигом.
вот линк код
в комментах не дает столько текста вставить
не я строил и не я планнировал. моя задача состояла в том, чтобы найти проблемы и повозможности помочь исправить без глобальной переделки продукта и его заморозки. Что и былосделано, с небольшими изминениями, получена производительность в ms в сумме. Клиент доволен, заказчик доволен. продукт спасен, еще и на шару.
Еще раз. второй запрос с суммарным подсчетом вам MySQL не выдаст даже при любых индексах и любой оптимизации. Это ей просто не по силам. Линейные выборки да, но не суммарные из подзапросов. И дальее мы снова идем на PHP и считаем там.
Речь вообще не шла о базе, база была как отправная точка у разработчиков и что и как они дальше намудрили в проекте. Как ни извращайся но второй суммарный запрос c SUM() вы не сможете на MySQL получить одним запросом даже за минуту. И снова пойдете на PHP доделывать то что впринципе долдна делать база, и снова попадетесь на проблемы самого PHP и его болезни с Array. И в итоге вся задача была, показать то что нашел, как сравнил и что пулучил… но неожидал такого холивара на хабре, стоило только в чемто упрекнуть MySQL и ее приминении.
первый заброс выборка да, я умудрился до 0,7 времени разогнать, но вот сразу получить SUM() поверх выборки… муська уходит в небытие и безвозвратно, даже уменьшение периода в 3-5 дней, так и не дождался, т.е. полюбому нужноили через временные таблицы гонять или снова на PHP доделывать. И снова получается, то что модно выполнить за один проход — делаем разные манипуляции и обходы.
вся суть в проблеме темплейтов которые грузятся через Ajax.
Кто знает об этой проблеме просто молодцы. Но я вижу таких около 90% того что есть щас в инете. Все девелоперы кто строят web 2.0, грузят все аяксом не задумываясь, и благо им непопадаются задачи с большими расчетами, потому как таких задач мало, и это больше к торговым площадкам относится, чем к другим задачам. Но проблема есть, многие не знают, и пост был на то и расчитан чтобы показать что может ожидать, а также для себя сравнить с другими платформами, хотябы ради интереса.
Кому было полезно, значит хорошо.
чистый массив данных в цифрах, еще и ужатый gzip занимает копейки, было проверено, и клиент его даже по инету получает за считанные ms что фидлером и было проверено. в итоге получив только 1 строку массива, клиент далее может строить любые графики и таблицы, меняя отображение. а до этого при самый оптимальных переделках, для php+mysql не удавалось даже к 5 секундам приблизиться. Да ещ еи отчет ранее строился готовый, значит коиент получал HTML с чартами и т.д. а это все хуже и дольше чем полученный вариант обработки на JS.
И да — это спец проект для клиента был, и понятно что на простеньком планшете где АРМ6 никто пользоваться не собирается.
Ну так для чиво я и создавал тесты и выводил цифры? Все также потому что увидел это в коде который я анализировал. Потому и создал пост чтобы поделиться этими цифрами и тем кто это видит в первый раз, может помочь пересмотреть свои проекты. Про базу было упомянуто, только чтобы показать, почему девелоперы вместо базы засунули обработку в PHP снова создав проблему очередную.
Я для себя в тестах просто получил вполне интересные цифры, решил вот поделиться… в итоге 99% коментариев уперлось в MySQL и завал минусами. Т.е. вся собранная статистика чисто до одного места, и тут все 100% только Гуру находться. А значит мои старания были чисто бредом… чтож… понял, учту, и больше не буду так делать. Для себя нашел чтото, и и ладно, остальные и так все знают уже давно.
C индексами все ок. причеv создавался тест отдельно на подобии кода под MS SQL, пробовал разные варианты, игрался и с join и с другими вариантами, тотже выбор нужной записи по MIN() проигрывал в скорости в сравнении с LIMIT 1, в тоже время у SQL Server оказалось, все наоборот, MIN() выиграл в скорости у TOP 1.
Но тут больше время видимо у MySQL забирает нарезание памяти для подзапроса.
Дело в том что, если в под запрос добавить ограничение выборки повторив:
ev2.event_date BETWEEN '2012-1-1' AND '2012-1-31'
то время будет отличное, но так нельзя, иначе потеряются концовки событий, которые могут быть уже за пределами периода.
Также условие IF() или CASE() добавляют сложностей. Селив примере поставить статично type=1 (...type=2) то расчет будут почти идеальный, но это снов ане подходит, так как групп много, и у каждого эвента своя пара, потому и нужно указывать, для какого варианта, что является концом.
Вы все увидели просто выборку и все, и понеслась что я ламер и все остальное уже неважно.
А тем более это важно для Энтерпрайз приложений. Я планировал перейти с Flex на HTML5, из-за шунихи вокруг смерти Флеша и Флекса… но я не рискну написать энтерпрайз приложение на открытом коде, это бред полный.
Да и не каждый Флеш можно декомпилировать. У Адоба давно есть методы защиты Флеша от декомпиляции той о которой вы говорите.
Отвечу просто — нету нИ одной задачи на канвасе которую флеш не сможет выполнить да еще с лучшими показателями. В тоже самое время — колосальное кол-во задачь которые HTML5 просто не в состоянии осилить, даже при большом желании.
После долго мучение с портированием Флеш игры в HTML5 я для себя понял одно! Мне проще и быстрее в сотни раз, переписать 2D игру в 3D. И это было проверено на практике. Имея такие фреймворки как Away3d, Alternativa3D, Flare3D и др., уже вчера можно было в очень короткие сроки, реализовать свои идеи.
Потому HTML5 завтра все еще будет предлагать сырую 2D платформу, а Флеш уже вчера предлагал полноценную 3D платформу и не только.
Флеш как раз все дальше и дальше отрывается от HTML5 и шансов что HTML5 когдато догонит Флеш, практически никаких. Разве что если Adobe таки решиться его похоронить.
Конкретно на сегодня:
— Флеш уже давно не рендерит весь слой в 2D а только ту часть, в которой происходит изминение что дает максимальный ФПС. Тотже HTML5 все еще делает по старому, каждый фрейм идет рендеринг, и еще не скоро дойдет до этапа аналогичному во Флеш.
— Флеш уже прошел все пути в 2D, и сейчас просто ищет оставшиеся пути его ускорения и оптимизации… больше там развивать нечего для них
— развитие в 3D у Флеша уже дальше чем HTML5 в 2D
По этому «фора Флешу»… вы или неправельно выразились, так нужно было сразу исправить. Или вы далеки от понимания, но решили чисто не забыть кинуть камень в сторону Флеша как это любят делать на Хабре и заработать себе лишнюю карму.
Все время следил за HTML5, и доси не понимаю всего бреда вокруг него, как и с шумихой вокруг Ajax в свое время, притом что DHTML изначально был, хрен знате сколько лет и прекрасно работал.
Потдавшись шумихе… таки решил попробовать переписать свою игру с Flash на HTML5… в итоге убил тучу времени, но понял что это тупик.!!! Причем тупик по всем фронтам.
1. Код полностью открытый! Нафиг оно мне такое нужно? Я сам взломал много таких игр и быстро пропал интерес… код раскрыт и делай что хочешь.
2. Как мою игру отдать всем в онлайн, на томже Facebook если оргомная аудитория пользователей прекрасно сидит на ХП с IE8 в котором толком ничего не заработает. даже не все framework стабильно работают под IE9.
3. Провел пару тестов на плантшетах с АРМ 6/7 и был в ужосе.
т.е. Чтобы создать свою, допустим соц.игру на HTML5, мне придется убить просто огромное кол-во времени, собирая все покусочкам, оптимизируя безконечно. И писать тучи вариантов игры, чтобы не потерять часть аудитории?
И при всем при этом, вижу почти каждый день, как минусуют любого кто хоть както заступится за Flash. Похоже на хабре это слово стало синонимом с Microsoft, и несет за собой падение кармы упоминувшего в суе. И это IT-шники? :(
Т.е. еще раз уточню… база тут непричем. Сменить сервер возможности небыло, чтото кординально менять тоже, а спасать нужно было. Вот и была работа в поиске всех больных мест, а чисто для себя сравнения с другими платформами.
Да и не планировали все это специально… для себя они ограничивали в 7 дней и жили с этим. Случайно так вышло, что мне получилось взглянуть и стало инетресно почему так много времени. Попробовал базу, ужасно долго, со своей стороны решить эту проблему не мог не имея доступа к базе. Начал ковырять дальше, увидел обработки огромных масивов на PHP и ужасные тормоза… также начал выяснять и для себя сравнить в других платформах, так как есть другие задачи на asp.net и node.js… что ыбло под рукой и легко перекинуть то по быстром уи проверил. Цифры были очень интересные, решил поделиться… за что нахватал минусов по самые нехочу.
Решение проблемы, было таким:
— в базе оставить только выборку линейную, время в ms
— в php забрать данные с базы удалив все обработки и отдать ввиде data[] массива через ajax клиенту, также время на затраты в ms
— в интерфейсе сидит function переписанная из php в javascript, которая считает всю аналитику за 110ms настороне клиента, тутже создав чарты, плюс возмодность по разнымопциям перерисовать чарты. имея исходники данных а не только суммарные, JS на клиенте может с легкостью за 110ms снова все пересчитать уже по другим группам, хоть по дням, хоть по месяцам, хоть сами группы превернуть… т.е. имеем полностью динамичный клиент, без лишнего обращения к серверу и без потери времени на расчеты.
т.е. в итоге получилось даже лучше, чем есле бы удалось домучать mysql. JavaScript на стороне клиента в чистом виде, позволяет совершать довольно большие расчеты и тутже все отображать не обращаясь к серверной части.
Как помне, то в идеале иметь серверную часть на nodejs+mongodb чисто для приема и выдачи даных клиенту. а все остальное это JS и темплейты, которые один раз загружаются либами, а далее получая только чистые данные от срвера, можно строить и рисовать как душе угодно. Клиент считает все с легкостью, сервер почти полностью разгружен от лишних запросов. gzip доводит размер общения клиента и сервера до смешных пакетов.
сразу замечу что MS в самой простой и тупой Web редакции, без танцев с бубном войти чрез форточку вместо парадного входа — выполняет суммарный скрипт менее чем за 1 сек, в виртуалке с 1 ядром и 1гигом.
вот линк код
в комментах не дает столько текста вставить
Кто знает об этой проблеме просто молодцы. Но я вижу таких около 90% того что есть щас в инете. Все девелоперы кто строят web 2.0, грузят все аяксом не задумываясь, и благо им непопадаются задачи с большими расчетами, потому как таких задач мало, и это больше к торговым площадкам относится, чем к другим задачам. Но проблема есть, многие не знают, и пост был на то и расчитан чтобы показать что может ожидать, а также для себя сравнить с другими платформами, хотябы ради интереса.
Кому было полезно, значит хорошо.
И да — это спец проект для клиента был, и понятно что на простеньком планшете где АРМ6 никто пользоваться не собирается.
Я для себя в тестах просто получил вполне интересные цифры, решил вот поделиться… в итоге 99% коментариев уперлось в MySQL и завал минусами. Т.е. вся собранная статистика чисто до одного места, и тут все 100% только Гуру находться. А значит мои старания были чисто бредом… чтож… понял, учту, и больше не буду так делать. Для себя нашел чтото, и и ладно, остальные и так все знают уже давно.
Но тут больше время видимо у MySQL забирает нарезание памяти для подзапроса.
Дело в том что, если в под запрос добавить ограничение выборки повторив:
ev2.event_date BETWEEN '2012-1-1' AND '2012-1-31'
то время будет отличное, но так нельзя, иначе потеряются концовки событий, которые могут быть уже за пределами периода.
Также условие IF() или CASE() добавляют сложностей. Селив примере поставить статично type=1 (...type=2) то расчет будут почти идеальный, но это снов ане подходит, так как групп много, и у каждого эвента своя пара, потому и нужно указывать, для какого варианта, что является концом.
Вы все увидели просто выборку и все, и понеслась что я ламер и все остальное уже неважно.