Вы задавались кода-нибудь вопросом, сколько 'весят' конкретные объекты вашего флэш-приложения? К сожалению, (или к счастью?) свойства size у них нет. Но в AS3 есть класс ByteArray с массой полезных применений (например, быстрое клонирование сложных объектов). И у класса ByteArray есть свойство length и метод writeObject, с помощью которых легко измерить вес объекта в байтах:
ByteArray
length
writeObject
var ba:ByteArray = new ByteArray(); trace("ByteArray size: " + ba.length);// 0 bytes var p:Point = new Point(100, 100); ba.writeObject(p); trace("ByteArray size with point: " + ba.length);// 11 bytes
Это не размер объекта в памяти.
А я и не говорил, что это размер объекта в пямяти. В чем именно это размер объекта - вот хороший вопрос.
Но!
Нет сомнений в том, что это все же именно размер объекта, а не, скажем, его цвет, не так ли? =P
В ближайшее время я поразмыслю о том, как сопоставить эти данные и размер реально занимаемой памяти. Сейчас на ум приходят волнующие конструкции из рекурсивного обхода всего приложения.
flash.sampler.getSize
Это размер в формате AMF.
>> Это размер в формате AMF.
Похоже на правду.
>> flash.sampler.getSize
Очень интересно: Гугл знает только один ответ на этот запрос, и он на японском. Можешь поподробнее?
открываешь флекс, запихивает параметром объект и получаешь размер в памяти. даже мувиклипы хавает.
это функции появившиеся в 3м флексе. есть очень даже любопытные. http://livedocs.adobe.com/labs/flex3/langref/flash/sampler/package.html
Полученный размер 11 - это объект в AMF формате, запакованный zip. В памяти объекты хранятся в другом виде. И getSize(p) показывает 24 байта. Что, в общем то, логично, т.к. экземпляр точки - 3 координаты типа Number (который по спецификации весит 8 байт).
Впрочем, думаю, что 24 байта - это чистые данные, но ещё должны где-то храниться и вспомогательные, типа уникального идентификатора, адреса в памяти, ссылки на класс.
Если всё ещё не веришь, что writeObject совершенно не то, попробуй создать экземпляр какого нибудь класса и засунуть в ByteArray, а потом оттрейсь содержимое ByteArray. Среди непонятных запакованных байт ты увидишь знакомые названия параметров.
AMF, на мой взгляд, поганый формат для хранения и передачи данных. По сути, он воспринимает переданный объект как динамический (т.е. не смотря на класс). Он хранит каждое поле в виде "название поля = значение". Поэтому, записав в ByteArray (или отправив в сокет), ты не получишь экземпляр класса, который ты передавал. Вместо этого будет безликий Object с полями. Ну и учитывая, что название поля может быть не "x", а, например, "mouseInteractionEnabled", то представляешь, сколько лишнего хлама будет содержаться в итоговой последовательности байт?
По этой причине мы сразу отказались от этого формата, написав свой собственный, с контролем типов, с возможностью передавать списки, массивы, вложенные структуры. При этом если отправили Point3D, то и получили экземпляр Point3D. При этом размер передаваемых данных даже (пока) в незапакованном виде выигрывает по сравнению с AMF в несколько раз.
BlooDHounD, спасиб большое за ссылку, я этого еще не видел, а так столько вкусного :)
Антон, ты пожалуй прав. Но дело в том, что не каждый проект пойдет на написание собственного формата данных, пусть и более эффективного, чем AMF.
Я пытаюсь понять, почему AMF3 получился таким: с хранением названий полей, с голым объектом. Может, его пытались сделать максимально универсальным?
По поводу того, что внутри AMF - вопрос вроде понятный, но не до конца (про спеку AMF3 знаю, но признаюсь - до сих пор не изучил). С одной стороны, там голый Object. Но с другой - как тогда срабатывает registerClassAlias, успешно распознавая в пришедшем с сервера AMF3 классы приложения? Очевидно, внутри AMF-сообщения есть мета-информация о том, как его понимать, какие классы в нем содержатся?
Кстати, обрати внимание: сегодня выходит новая версия AMF.
И собственно по теме этой записи: я считаю, что это любопытно — сравнить размеры разных объектов, если используешь AMF (да и просто чтобы узнать хотя бы приблизительно, насколько Shape дешевле Sprite).
Антон Волков, точно, вчера разбирался с форматом, тоже эта глупость удивила. Но дело тут ведь не в динамичности класса. Нам необходимо задать очередность перечисления значений - в каком порядке будут указаны значения для их последующего присваивания соответствующим свойствам класса (так как в ассоциативном массиве порядок элементов не определен). Ну и сделали бы как в синтаксисе insert в mysql - сначала одно names, а потом сколько угодно values. Кстати, разработчики PHP допустили ту же ошибку ;) - посмотрите результат serialize. А так со всем этим начинаются лишние проблемы - http://pecl.php.net/bugs/bug.php?id=12668
классы распазнаются Flex-приложениями на основе маппинга классов. [RemoteClass], [Transient] к тому же, кроме имён, он ещё записыват тип данных. чтобы поля были не обстрактными ( * или Object ), а имели типы String,uint и т.д. к тому же это нужно что бы тупо что бы знать что читать.
> сравнить размеры разных объектов Вот, возьмём пример из моего коммента. Экземпляр одного класса имеет единственное булевское поле "mouseInteractionEnabled". В AMF он займёт 29 байт, а в памяти 12. А другой, например, Point, соответственно 11 и 24. И как при таком раскладе корректно сравнить? Даже примерно? ;)
Я склонен думать, что некоторые разработчики - сторонники прямых методов, или так называемой brute force. Такие решения как правило работают стабильно из-за своей примитивности, но качество работы оставляет желать лучшего, потому что не уделяется должного внимания оптимизации кода. Пока занимаешься разработкой сравнительно простых приложений на это можно закрывать глаза, но когда система усложняется, когда начинается использование всех библиотек вместе, начинаешь тихо обуевать. В этот момент разработчик либо упрощает задачу, ссылаясь на техническую невыполнимость, либо пытается вставляет оптимизации поверх библиотек (по нашей терминологии - вставляет костыли), либо пишет свои либы.
Мы пошли по третьему пути, но нам это встало в год разработки. Сделали сетевой протокол вместо AMF, свой GUI вместо стандартного флексового, свой 3D-движок вместо PV3D.
Вопрос - многие ли могут позволить себе такие затраты ресурсов? А не стоит ли разработчикам библиотек уделять больше внимания оптимизации (и не расчитывать на рост гигагерцев с гигабайтами)? Я конечно понимаю, что горящий зелёным пламенем кубик - это стильно; пусть процессор нагружен под завязку, а браузер висит. Но что произойдёт, если разработчику понадобится совместить в одном приложении и кубик, и таблицу, да ещё и загрузить в неё данные из сокета?
> А не стоит ли разработчикам библиотек уделять больше внимания оптимизации (и не расчитывать на рост гигагерцев с гигабайтами)?
Пардон, что вмешиваюсь - все ниже - мое собственное мнение, :)
Либы разработчики пишут под некоторые свои собственные задачи. Результат иногда дарится комьюнити. Причем чаще всего заказчики (свои и комьюнити) больше хотят фич, нежели оптимизацию. Разработчики начинают задумываться над оптимизацией, когда это может стать хорошей фичей.
Кроме того, за хорошие библиотеки надо платить. Универсальные (brute force), как правило, окупить проще - потому что они нужны многим, чтобы работало "хоть как-то", и эти многие способны отдать небольшую денюжку за нужный функционал. Уникальные библиотеки очень сложно окупить (скажем, не думаю, что кто-то способен адекватно оплатить вам разработку движка) - и они создаются в расчете на один проект. Вряд ли кто-то возьмется за разработку похожей игры.
Хотя я все равно кричу "ура" тем, кто пытается улучшить этот сложный и непонятный мир :)
Ты прав. Но я говорю о простейших сравнениях встроенных объектов в их дефолтном состоянии (а также о другом случае — сравнениях не занимаемой памяти, а передаваемых через AMF данных). Например, все тех же Shape и Sprite, пытаясь определить, сколько реально я могу выиграть, переделав проект с тысячами спрайтов, заменив каждый неинтерактивный спрайт без потомком простым шейпом.
Немного о различиях в AMF-размерах и размерах в памяти: Размеры пустых Shape, Sprite и MovieClip в формате AMF (замеряем через ByteArray.length): Empty Shape size in AMF format, bytes: 406 Empty Sprite size in AMF format, bytes: 672 Empty MovieClip size in AMF format, bytes: 1
Размеры тех же объектов в памяти (замеряем методом flash.sampler.getSize:) Shape size in bytes: 232 Sprite size in bytes: 456 MovieClip size in bytes: 488
Твое утверждение здесь иллюстрируется: по AMF пустой Sprite больше пустого Shape в полтора раза (~1.6), а по занимаемой памяти — почти в два (~1.9). Интересно также то, что AMF отказывается понимать размер мувиклипа (вспоминаются слова BloodHound о том, что "[getSize] даже мувиклипы хавает").
Сейчас-то я хорошо понимаю, насколько наивным был этот пост (хотя! у этого метода с ByteArray.length есть одно очень полезное применение при хранении данных в массиве Local SharedObjects, но об этом потом).
Я рад, что этим постом вызвал интересную дискуссию, из которой сам узнал много нового — практически все комментарии дали пищу для размышлений, ну а ты просто всех порвал ;-)
По поводу либ... писать свои решения — нужно быть уверенным в себе и иметь тот самый запас времени, а еще — точную и стройную архитектуру проекта. На своем последнем большом проекте я осознал, что очень и очень нужно подтянуть мне этот хвост.
Спасибо! :)
Не за что, Рост :) Для меня это явно наболевшая тема.
P.S. Кстати, перестал работать "Наблюдать процесс отладки"
у нас кстати тоже свой протокол, свои UI, вот только трагедии не вижу :) есть задача - выделяем ресурсы делаем.
Тем более.
Трагедия в том, что если бы адоб-кодеры подошли к работе более ответственно, мы с вами бы потратили время на другие задачи по развитию проектов вместо разработки проприетарных библиотек.
Понятно, что это всё риторика. И так и будем продолжать "есть задача - выделяем ресурсы, делаем". Но может хоть кто нибудь задумается? ;)
я не уверен, но мне кажется что ниодин из языков программирования не был изначально великим и могум... не были правельно написаны компоненты... и всё чему сейчас достигли "монстры" (php, perl, ruby и т.д. да вообще наверно все языки) это всего лишь то что из их сделали их фанаты. всё зависит от доспутных пользователю библитек. ждём десятки и будем надеятся, что нашумевшая портация CPP, даст разработчикам возможности разрабатывать свои низкоуровневые библиотеки, что на мой взгляд приведёт к резкому росту возможностей флэша.
Возможно, открытие исходников Flash Remoting позволит сделать шаг вперед, к более зрелому официальному ремоутингу?
Вычитал в официальной спеке по AMF3 вот это и крепко задумался:
In AMF 3, Strings, Complex Objects (which in AMF 3 is defined as anonymous Objects, typed Objects, Arrays, Dates, XMLDocument, XML, and ByteArrays) and an Object Type's Traits can now be sent by reference.
Сказано, что типизированные объекты в AMF3 поддерживаются, так же как и передача строковых значений по параметру (For AMF 3 a string can be encoded as a string literal or a string reference. - в самом верху четвертой стр. А внизу ее же есть полное перечисление улучшений в AMF3, 2.1 Summary of improvements - там слово by reference встречается вдохновляюще много раз). Есть таблица строк, так же как и таблица traits-объектов для класса, и таблица ссылок для Комплексных Объектов (куда входят Объекты, Типизированные Объекты и Кастомные Классы)).
То есть спека говорит о том, что AMF3 весьма серьезно опимизирован. И в связи с этим возникает у меня мысль: известная нам опенсорсная реализация AMF-обмена (Fluorine / AMFPHP) не в полной мере использует возможности AMF3, это скорее что-то, что работает хоть как-то а не так, как задумывалось. Выскажу догадку о том, что Adobe реализовала функционал AMF3 в своем Data Services более полно, чем опенсорсные разработчики. На это указывает также и то, что в своей кустарной расшифровке формата AMF3 Кевин Лангдон (автор известного и, по-моему, лучшего AMF-сниффера Service Capture) не предоставил той полноты данных, которую мы видим в только что опубликованной официальной спеке. Кевин не упоминает о traits-объектах, а ведь именно они несут информацию о свойствах типизированных объектов. С другой стороны — ServiceCapture показывает типы даных внутри AMF3-пакетов. Но почему тогда Лангдон не выложил этого в своей спеке?
Хочу выдвинуть осторожное предположение, что мы, думая что пользуемся AMF3 во всей его красе, имели доступ к части заложенных в него возможностей. Под словом "мы" я имею в виду тех, кто использует OpenSource-вариант Remoting-технологии.
Сейчас Адоби открывает свой официальный ремоутинг-проект для переноса его на другие платформы — значит, можно надеяться на апдейт тех же Fluorine / AMFPHP и повышение производительности работы с ними.
Вот такие мысли.
P.S. Кое-что поправил в скрипте подписки на комментарии - проверьте, пожалуйста, работает ли теперь.
