Tempos de acesso de acordo com o tipo de memória

Pô pessoal, será que ninguém aqui já passou por isto ?

Será que a maioria se vira com o WTK e não usa/não tem aparelho real nos testes ?

Fico com a impressão de que são poucos os gatos pingados aqui no fórum que realmente tem experiência no mundo real, dito, possuem um celular com pelo menos um “Olá Mundo” rodando…

O maior problema de manter todos dados do teu recordstore em memoria é que o heap da grande maioria dos celulares é muito menor que o espaço de cold storage e em alguns casos são compartilhados.

Eu tenho um 3100, que tem 512kbytes de storage e um heap de poucas duzias de kbytes, ou seja, sou limitado pelo tamanho do heap.

Existem outros fatores, como o consumo de energia estar relacionado ao uso de heap.

A melhor solução que eu encontrei foi implementar um cache LRU para o recordstore com suporte a read-thru para pesquisar sem causar thrashing no cache e readahead para acelerar leitura sequencial. O consumo de memoria é mínimo, o ruim foi que o código inflou sensivelmente.

Tô justamente perguntando sobre memória, pois estou saindo do uso do design pattern flyweight para cair numa dessa de manter 100 objetos em memória representando meus registros…

Por causa do flyweight, tô tendo que fazer muita deserialização, ou seja, reconstruir o estado do objeto a partir do array que pego via getRecord.

Se faço isto apenas uma vez e mantenho cada objeto em memória, vou gastar em torno de uns 9Kb para manter tudo em memória, mas não tenho mais o overhead de fazer a deserialização a cada vez que eu mudar de item.
A deserialização implica em eu criar um objeto String para cada membro da classe. Se eu tiver 10 membros, só em deserializar um item, vou ter 10 objetos String. Se eu tiver 100 items, vou ter 1000 objetos String. Isto, por exemplo se eu montar uma lista uma única vez. Imagina eu repetir isto várias vezes durante o ciclo de vida da aplicação.
Tenho um Siemens M50 cujo Garbage Collector não tá dando conta de desalocar os objetos na periodicidade que preciso. Resultado: Exceptions Out-of-Memory eventuais…

Por isto hoje decidi abandonar o flyweight e tentar esta abordagem de trabalhar tudo em memória e não ficar naquela de lê do RecordStore, deserializa e acessa os membros. Mudando, eu vou fazer a deserialização uma única vez para cada item depois não mais.

No Siemens M50 talvez o bicho pegue, afinal, qtde de memória livre nele as vezes chega a patamares críticos como 5Kb !

Já em outros, tenho memória a dar com pau !

Você acha que eu mantendo em memória tudo isto eu gasto mais do que a tarefa de deserializar que atualmente faço ?
Hoje eu vejo que deixou muitos objetos orfãos rapídinho e tenho bastante processamento…

Enfim, obrigado por sair do esconderijo e dar sua opnião !!! :lol:

Serialização custa caro se envolver a criação de muitos objetos, caso contrario o custo é bem menor que a leitura do RS.

Uma opção seria reutilizar os flyweight’s para deserializações sucessivas de Objetos diferentes. Essa é uma solução meio desesperada já que vai exigir um book-keeping consideravel para evitar a alteração de objetos já em uso.

Eu nunca tive de trabalhar com restrições de memoria muito severas, então não posso te ajudar muito.

O tunning depende muito da suas necessidades, ainda mais que o tamanho do resultado também importa.