«Для кода в eval нету прокомпиляции и кучи других оптимизаций, потому он однозначно медленнее»
— Зачем нужна прокомпиляция и оптимизация для управляющих команд?
Она не нужна. Вы путаете данную ситуацию с случаем использования «костылей», когда из-за «ломанной» логики приложения передаётся код функций.
TheShock, я знаю вашу позицию очень хорошо. Понятно дело, что в идеальном fullajax-приложении всё строится на методах call и apply, но это требует лишних заморочек с архитектурой сервера и клиента.
Я же рассуждаю чисто практически: пусть код пришедший с сервера выполняется в 4 раза медлее (пользователь всё равно не уловит эти 0.004 сек), но зато я могу просто отправлят управляющие конструкции, не заботясь об обёртках и передачи параметров.
Да, JS-код можно загружать без конструкции eval, только работать это будет точно так же как eval. Быстрее eval выполнение кода производят только методы apply и call, но они требуют более сложной логики сервера.
Но суть не в скорости выполнения, не прозрачности кода, а логике приложения, которое получается в конце. Используя костыли, заменяющие eval, вы в итоге получаете нелогичный код с проблемами, как у автора вопроса. Используя eval можно, напротив, избавиться от лишних конструкций организовав прозрачную и простую связь между клиентом и сервером.
Зачем?
Данные в Application Cache загружаются фоново, не задерживая основную загрузку. После загрузки отображаются моментально, т.к. берутся из кэша. Никаких лишних телодвижений.
Application Cahe изначально задумывался для выполнения этих задач.
Watch — подписка на определённого автора. Её часто используют для сохранения ссылки на интересные работы. Причина проста — watch не отображается в профиле пользователя у других пользователей, типа «секретная» закладка.
«Хм, ну это общеизвестно. 10.5. Data Type Storage Requirements: […] For BLOB and TEXT data, the information is stored internally in a different area of memory than the row buffer. […]»
— Я не об этом. Я про то, что СУБД проще вернуть несколько байт, чем десятки килобайт.
«Text/blob хранятся отдельно от самих строк, поэтому не должны влиять на скорость выборки. „
— Неужели? По моему вы очень ошибаетесь.
“Но, судя по структуре таблицы, там только запросы по индексу должны быть, и на скорости отражаться не должно.»
— Крайне маловероятно, что это полная структура таблицы.
«если «преимущество СУБД — это поиск», то зачем сфинкс?»
— Некоторые люди боятся сторонних решений.
Да, СУБД хранит данные в тех же файлах, но:
— СУБД лишний посредник;
— Таблица с полями TEXT или BLOB не может быть fixed;
— Кэширование СУБД крайне плохо ведёт себя при работе с объёмными выборками.
Единственное критическое преимущество СУБД — это поиск. Но если используется Sphinx, то и это не проблема.
Для спрайтовой анимации есть определённые ограничения:
— Количество анимированных объектов видимых в одно время;
— Точность позиционирования анимации;
— Количество кадров в анимации;
— и т.д.
Например, поворот в объёме можно сделать спрайтами, но 3-4 таких «поворачивающихся объектов» одновременно заставят браузер повиснуть.
Полос не видно?