Aumento de memória/processamento em Bindable

[Pergentino Araújo]

Olá pessoal,

alguém já viu em algum documento (de preferência oficial), que fale a respeito do possível crescimento de memória e/ou processamento quando é utilizado muito (mas muito mesmo) o esquema de Bindable em objetos/propriedades?

--
Atenciosamente, Pergentino Araújo.
Arquiteto Java/Flex
MSc. Profissional - Engenharia de Software
Adobe Certified Expert - Flex 3 with AIR

[Gabriela Trindade Perry]

yeap.
Uma vez eu até me lembro de ter quetsionado o porqeu de tanto bindable
pra todo lado... Até constantes são bindables, embeds são bindable....
http://rjria.blogspot.com/2008/02/flex-optimization-beware-bindable-vos.html
http://www.sephiroth.it/weblog/archives/2009/07/bindable_no_thanks.php
http://www.screenshot.at/blog/2009/04/18/databinding-under-the-hood-part-1-performance/

[Pergentino Araújo]

Bacana Gabriela !!!

dei uma olhada em um dos links, e a diferença realmente é absurda:

now launch the script and in the output I have this result

total execution time: 2381 ms
memory usage: 5924 kb

NOW. Remove the [Bindable] property from the RGB class and launch again the test script. See at the output console and the new results are:

total execution time: 236 ms
memory usage: 2720 kb

Agora, o cara lá fez 100.000 operacões/instanciações... aí também é brincadeira né !? rsrsr

Eu me preocupo mais com memória do que com processamento, pois eu sei que a qtd na minha app não vai chegar nem a metade da metade da metade disso ae rsrsrs.

Alguém fez um teste na prática em uma app ?

[]'s

--
Atenciosamente, Pergentino Araújo.
Arquiteto Java/Flex
MSc. Profissional - Engenharia de Software
Adobe Certified Expert - Flex 3 with AIR

2009/11/4 Gabriela Trindade Perry <gabrie...@hotmail.com>

[Mário Júnior]

Sinceramente... no final - e em um caso real - a diferença é tao pqna q estou mais me preocupando com UX da app doq alguns bits de memoria, ou milisegundos de processamento.

=D

2009/11/4 Pergentino Araújo <jperg...@gmail.com>

--
Mario Junior
Enterprise Java / Flex Architectures
Adobe Certified Expert Flex 3 with AIR

Sofshore Informática
http://www.sofshore.com.br
+55 (48) 3337 2003
Rua Pastor Willian Richard Schisler Filho 452 sl 102, 88034-100 Itacorubi
Florianopolis SC Brasil

[Stefan Horochovec]

Ola

Eu não me preocupo tanto com isso, acredito que seja procurar pelo em ovo .... Tem mais detalhes para levar em consideração do que o Binding, como por exemplo: usar da melhor forma a RSL....

Abraços

Stefan Horochovec
Engenheiro de Software
Adobe User Group Manager - FlexDuck
Blog: http://www.horochovec.com.br/
Use Java, Flex e Linux

2009/11/4 Mário Júnior <junin...@gmail.com>

--

[Beck Novaes]

Hm... realmente o uso do Binding pode ser perigoso. O principal
problema é usar DTOs grandes e complexos que cujos dados aninhamos são
renderizados por diferentes telas. Neste caso, quando seu DTO chegar
ao Flash Player todo lugar que tiver usando Binding com esta cara vai
ser executado, ou seja, mesmo telas ocultas que renderizam um trecho
do seu complexo DTO consumirá processamento. Já vi aplicações ficarem
bem lenta pelo uso excessivo do Binding. Além disso, use Binding com
States se quiser cometer suicídio.

[]'s
Beck Novaes

[Gabriela Trindade Perry]

Sabe, acho que a gente tem que pensar que tem pessoas que nos leem e
que não tem tanta experiencia/conhecimento quanto nós (autores desta
thread). Neste post, por exemplo, todo os autores sabem muito Flex/
AS3. Eu me preocupo com um menino que começou a programar anteontem e
lê o Mario ou o Stephan - que são duas pessoas que têm o maior
respeito do pessoal daqui - e que vai começar a colocar bindable em
constante, porque leu que os gurus "não se preocupam tanto com isso".
Ainda mais porque Flex é tão fácil, mas tão facil, que qualquer um
consegue criar uma appzinha básica (e depois não consegue fazer nem um
substr, basta olhar outros posts aqui...).
Então, pra quem está seguindo essa thread: pras apps do Stephan e do
Mario - que mesmo que eu não tenho visto tenho certeza que estão bem
projetadas - ficar catando binding desnecessário é mesmo "procurar
pelo em ovo". Até porque não deve ter binding sobrando ali.

Quem está começando deveria sim se preocupar com isso.

[João Fernandes]

Concordo com o Beck. Um dos principais problemas do Bindable é que
utiliza o default PropertyChangeEvent que é feito o dispatch sempre que
o setter é executado (e o seu valor é diferente do que estava
actualmente). Existem várias formas de optimizar o código, a simples
substituição de

[Bindable]
public var prop1:String;

por
[Bindable(event="prop1ChangeEvent")]
public function get prop1():String{}
public function set prop1(value:String):void{}

poderá fazer uma grande diferença.
--

João Fernandes

Adobe Certified Expert
Adobe Community Expert
http://www.onflexwithcf.org
http://www.riapt.org
Portugal Adobe User Group (http://aug.riapt.org)

[Mário Júnior]

Oi Gabi.

Entendo sua preocupação, e acho válida.. então, deixa eu tentar reformular minha resposta.


Obviamente que não faço tudo com Bindable ... por exemplo, constantes e embeds realmente são toscos usar Bindable. Outra coisa legal é oq o Joao Fernandes disse, sobre usar customEvents para detectar mudanças nas propriedades e não o "default" PropertyChangeEvent (q por default é usado pelo ObjectProxy... esse cara sim precisa ter muito cuidado.)

Outra questão é com relação a criação dos componentes, principalmente com os commitProperties e UpdateDisplayList ... já vi gente querer criar filhos de algo no updateDisplayList qnd uma propriedade é alterada... tá errado e isso gera um consumo violento.

Com relação a Bindable e States.. o Beck já deu um bom exemplo de quando usá-los (só em caso de suicidio).

Outra coisa q pode ajudar, pra quem usa o esquema do ModelLocator é nao torna-lo totalmente [Bindable] mas, extender (com "x" mesmo =P) de EventDispatcher e usar o mesmo esquema q o Joao falou, colocando o um [Bindable(event="minhaPropriedadeChanged")]  no getter e fazer o dispatchEvent(new Event("minhaPropriedadeChanged")) no setter. Com isso vc torna "bindavel" só as propriedades q precisa e nao todo seu modelLocator.


Enfim.. são cudiados q já tomo "por default" e que nem me faz pensar muito sobre consumo de memória e milisegundos de processamento. Agora... se em algum momento eu precisar criar na minha view um [Bindable] var algumaCoisa ... e que ela seja crucial para algum behavior de algum componente qualquer q melhore a UX do meu usuario.. não vou exitar.. não mesmo!!! =D Vou lá e coloco mesmo... não vou medir qnts bytes ou qnts ms ela pesou na app, CLARO QUE aí entra o "feeling" de saber qnd o desempenho foi prejudicado. É uma balança... e o ponto de medida as vezes depende da experiencia do desenvolvedor.

Realmente... para aqueles que estao começando agora, preocupam-se sim com processamentos e consumo de memoria, mas não foquem só no uso (ou nao uso) do [Bindable] corram atras de life-cycle UIComponent... lazy instantiation... elastic racetrack .. marshalled slice.. deferment.. etc.

Pesquise por esse termos... já tem bons conteudos em PT.


Abraços!

2009/11/5 João Fernandes <joaopedromar...@gmail.com>

[thiagoalgo]

"corram atras de life-cycle UIComponent... lazy
instantiation... elastic racetrack .. marshalled slice.. deferment..
etc"

Ótimos temas para um post no blog hein Mario?

> 2009/11/5 João Fernandes <joaopedromartinsfernan...@gmail.com>

>
>
>
>
>
> > Concordo com o Beck. Um dos principais problemas do Bindable é que
> > utiliza o default PropertyChangeEvent que é feito o dispatch sempre que
> > o setter é executado (e o seu valor é diferente do que estava
> > actualmente). Existem várias formas de optimizar o código, a simples
> > substituição de
>
> > [Bindable]
> > public var prop1:String;
>
> > por
> > [Bindable(event="prop1ChangeEvent")]
> > public function get prop1():String{}
> > public function set prop1(value:String):void{}
>
> > poderá fazer uma grande diferença.
> > --
>
> > João Fernandes
>
> > Adobe Certified Expert
> > Adobe Community Expert
> >http://www.onflexwithcf.org
> >http://www.riapt.org
> > Portugal Adobe User Group (http://aug.riapt.org)
>
> --
> Mario Junior
> Enterprise Java / Flex Architectures
> Adobe Certified Expert Flex 3 with AIR
>

> Sofshore Informáticahttp://www.sofshore.com.br

[Eduardo Kraus]

Falando em RSL, no Flex 4 os RSL vem assinado digitalmente e se a data estiver errada não carrega a app.

Eduardo Kraus Desenvolvedor eduard...@gmail.com blog.mxml.com.br www.twitter.com/EduardoKraus

2009/11/5 Stefan Horochovec <stefan.h...@gmail.com>

[Daniel Vitor]

Olá pessoal,

vendo esse post aqui, fiquei realmente preocupado.
Parece mentira, mas criei a 2 dias uma nova classe (singleton) que
contem todas as imagens comuns que uso em praticamente todas as view
do sistema, como:

Pensei justamente o contrário do que foi dito aqui, mas pelo jeito
perdi um enorme tempo alterando os embed de cada view pela classe em
questão.
Meu raciocínio foi economizar memória carregando somente uma vez essas
images e compartilhando-as onde precisar.

agora pergunto, é melhor usar essa solução que abaixo, ou voltar
declarar em cada view seus embed?

segue abaixo a classe.

package
{
public class ImageCollection
{

[Embed(source="images/png/16x16/add.png")]
[Bindable] public var addIcon:Class;

[Embed(source="images/png/16x16/ok.png")]
[Bindable] public var okIcon:Class;

[Embed(source="images/png/16x16/remove.png")]
[Bindable] public var removeIcon:Class;

[Embed(source="images/png/16x16/new.png")]
[Bindable] public var newIcon:Class;

[Embed(source="images/png/16x16/edit.png")]
[Bindable] public var editIcon:Class;

[Embed(source="images/png/16x16/delete.png")]
[Bindable] public var deleteIcon:Class;

[Embed(source="images/png/16x16/left.png")]
[Bindable] public var leftArrowIcon:Class;

[Embed(source="images/png/16x16/right.png")]
[Bindable] public var rightArrowIcon:Class;

[Embed(source="images/png/16x16/up.png")]
[Bindable] public var upArrowIcon:Class;

[Embed(source="images/png/16x16/down.png")]
[Bindable] public var downArrowIcon:Class;

[Embed(source="images/png/16x16/search.png")]
[Bindable] public var searchIcon:Class;

[Embed(source="images/png/16x16/search_form.png")]
[Bindable] public var searchFormIcon:Class;

[Embed(source="images/png/16x16/print.png")]
[Bindable] public var printIcon:Class;

[Embed(source="images/png/16x16/keys.png")]
[Bindable] public var keysIcon:Class;

[Embed(source="images/png/16x16/open_padlock.png")]
[Bindable] public var openPadlockIcon:Class;

[Embed(source="images/png/16x16/close_padlock.png")]
[Bindable] public var closePadlockIcon:Class;

private static var images:ImageCollection;

public static function getInstance():ImageCollection
{
if (images == null)
{
images = new ImageCollection();
}
return images;
}


public function ImageCollection()
{
if (images != null)
{
throw new Error( "Já existe uma instância criada!" );
}
}

}
}

[RafaelViana]

Eu tenho uma classe parecida, mas no meu caso não uso Bindable.Só
deixo o Embed.

Porque Bindable é para obter todas modifcações/transformações (manter
atualizado todos lugares que dependem dessa instância) que algo obteve
durante o uso do sistema (minha visão sobre Bindables), e o caminho
dessas imagens e as imagens em si não sofrem alterações o Bindable se
torna desnecessário no meu ponto de vista.

[Daniel Vitor]

Realmente Rafael, retirei os [Bindable] de cada embed, funcionou
normalmente. Porém se eu retirar a [Bindable] da decalaração da
variável, ai não funciona, exemplo:

[Bindable] private var images:ImageCollection; -> Funciona

private var images:ImageCollection; -> NÃO Funciona


Ficou assim a classe:

package
{
public class ImageCollection
{

[Embed(source="../../../../../images/png/16x16/add.png")]
public var addIcon:Class;

[Embed(source="../../../../../images/png/16x16/ok.png")]
public var okIcon:Class;

[Embed(source="../../../../../images/png/16x16/remove.png")]
public var removeIcon:Class;

[Embed(source="../../../../../images/png/16x16/new.png")]
public var newIcon:Class;

[Embed(source="../../../../../images/png/16x16/edit.png")]
public var editIcon:Class;

[Embed(source="../../../../../images/png/16x16/
delete.png")]
public var deleteIcon:Class;

[Embed(source="../../../../../images/png/16x16/left.png")]
public var leftArrowIcon:Class;

[Embed(source="../../../../../images/png/16x16/right.png")]
public var rightArrowIcon:Class;

[Embed(source="../../../../../images/png/16x16/up.png")]
public var upArrowIcon:Class;

[Embed(source="../../../../../images/png/16x16/down.png")]
public var downArrowIcon:Class;

[Embed(source="../../../../../images/png/16x16/search.png")]
public var searchIcon:Class;

[Embed(source="../../../../../images/png/16x16/
search_form.png")]
public var searchFormIcon:Class;

[Embed(source="../../../../../images/png/16x16/print.png")]
public var printIcon:Class;

[Embed(source="../../../../../images/png/16x16/keys.png")]
public var keysIcon:Class;

[Embed(source="../../../../../images/png/16x16/
open_padlock.png")]
public var openPadlockIcon:Class;

[Embed(source="../../../../../images/png/16x16/
close_padlock.png")]

[RafaelViana]

Você inicia ela assim?

private var images:ImageCollection;

Se você está usando um Singleton você precisa pegar a instância atual
se não o objeto vai estar nulo?

private var images:ImageCollection = ImageCollection.getInstance();

Ou você inicia ele em outra parte do código?

Fiquei em dúvida agora porque com Bindable funciona?? Existe mais
código relacionado?

[Daniel Vitor]

Desculpe,

estou meio afetado hoje! rsrsrs

não postei o código inteiro.

images = ImageCollection.getInstance();

[Bindable] private var images:ImageCollection; -> Funciona

images = ImageCollection.getInstance();

private var images:ImageCollection; -> NÃO Funciona

images = ImageCollection.getInstance();

Devido a pratica de programação adotado, fazemos as delarações dos
objetos/variaveis antes do construtor da classe e no construtor ou
dentro de creationComplete (quando é o caso) a instanciação. Por isso
esqueci de postar a parte da instância.

Agora sim está tudo ai, a classe e a forma de instancia:

e nos objetos (ex: button) é feito assim:

<mx:Button id="Bnew" icon="{images.editIcon}" label="Cadastrar"
right="10" height="23" width="108" bottom="5" buttonMode="true"/>

Penso que agora está bem claro a forma de trabalho.

Abraço!

[RafaelViana]

Ok.Agora ficou mais esclarecido.

O Bindable está diretamente relacionado aos colchetes no icon do
botão, indicando que esses ícones são chamados de uma forma bindada
por isso a necessidade do Bindable na variável.

Agora deixo para a galera mais experiente uma dúvida que vai te ajudar
e também fico em dúvida ás vezes: No seu caso se você deixasse apenas
images.editIcon o compilador iria entender isso como uma string? ou
como a propriedade do mesmo modo que bindable?

Qual a diferença e quais casos que posso utilizar uma propriedade de
forma não bindável?

[Mário Júnior]

Pq nao usa logo static dentro da classe e abandona de vez esse singleton?

class ImageCollection {

[Embed(source=".../meuIcone.png")]
public static var meuIcone:Class;

}



<button icon="{ImageCollection.meuIcone}" />


Pronto! Nada de [Bindable] ... nada de getInstance()... simples assim.

Daniel, qnd a sua primeira thread rolou no grupo a Gabriela e eu ainda ficamos nos perguntando o porque disso, querer usar singleton para economizar memoria mas sendo q a instancia nunca é destruida... nao faz sentido.. acho q ela ainda chegou a te avisar no tópico.

2009/11/5 RafaelViana <rfl....@gmail.com>

[RafaelViana]

Mario, saberia explicar porque {ImageCollection.meuIcone} e não
ImageCollection.meuIcone dentro da propriedade? Porque se faz uso dos
colchetes (else não sabem apenas para váriaveis bindáveis?)

On 5 nov, 22:14, Mário Júnior <juninho...@gmail.com> wrote:
> Pq nao usa logo static dentro da classe e abandona de vez esse singleton?
>
> class ImageCollection {
>
> [Embed(source=".../meuIcone.png")]
> public static var meuIcone:Class;
>
> }
>
> <button icon="{ImageCollection.meuIcone}" />
>
> Pronto! Nada de [Bindable] ... nada de getInstance()... simples assim.
>
> Daniel, qnd a sua primeira thread rolou no grupo a Gabriela e eu ainda
> ficamos nos perguntando o porque disso, querer usar singleton para
> economizar memoria mas sendo q a instancia nunca é destruida... nao faz
> sentido.. acho q ela ainda chegou a te avisar no tópico.
>

> 2009/11/5 RafaelViana <rfl.vi...@gmail.com>

> Sofshore Informáticahttp://www.sofshore.com.br

[fabiophx]

"No seu caso se você deixasse apenas
images.editIcon o compilador iria entender isso como uma string? ou
como a propriedade do mesmo modo que bindable?"

O compilador irá ver como string, se não me engano, dando erro.

Em complemento ao código anterior poderia setar a propriedade icon no
método createChildren.

[]s

Fabio da Silva
http://fabiophx.blogspot.com/

[Mário Júnior]

O uso de colchetes dentro do MXML não é só para binding... serve, também, para vc inserir instrucoes AS3 inline.

2009/11/6 fabiophx <fabiop...@yahoo.com.br>

[Mário Júnior]

Complementando... pode ser q o compilador lance um Warning avisando q não poderá detectar mudanças na variavel por ela nao ser [Bindable]. É só ignorar. Como já falamos antes, o fato dela ser static / const / embed nunca fará com q ela mude mesmo, então não faz sentido que ela seja [Bindable].

2009/11/6 Mário Júnior <junin...@gmail.com>

[Eduardo Kraus]

Com Embed faz assim: [Embed(source="images/png/16x16/add.png")] public const addIcon:Class; Lembre-se, constantes não podem ser alteradas. Também não precisam de Bindable.

Eduardo Kraus Desenvolvedor eduard...@gmail.com blog.mxml.com.br www.twitter.com/EduardoKraus

2009/11/5 Daniel Vitor <dvlu...@gmail.com>

[Gustavo Kawamoto]

O problema de usar const para isso é quando estamos usando o asdoc para documentar. Ele não consegue documentar porque está definido como constante mas não tem um valor padrão já atribuido. Chato né? :\

--
Gustavo Y. Kawamoto

2009/11/7 Eduardo Kraus <eduard...@gmail.com>