Re: [Jajuk-dev] Files Tree Lazy Loading

[Bertrand F. <ber...@fl...>]

Ok, thanks for the tips. I'm not sure if we need to dig this further as the
application responsiveness is probably more important than the memory usage
(given the amount of memory we now own on our moden boxes)...I agree that
char array comparison would be far longer, even using Arrays.equals()
method...

On Wed, Nov 25, 2009 at 4:35 PM, Dominik Stadler <dom...@gm...>wrote:

> Hi,
>
> On String: I did a rough calculation, it would be possible to save aprox
> 3.2M (65600 IDs with 2*25 bytes for char[] plus two times 4 for two longs)
> for a 27k collection where the overall heap was at 174M when I measured, but
> goes down to 90M at times. So roughly 2-3% gain would be possible with this.
>
>
> However this would probably cause a few complicated things, e.g. the
> comparison with == that we do currently would not work any more unless we
> "cache" these byte arrays somewhere for lookup to build our own "intern()"
> functionality or do a normal comparison now, not sure if this would impact
> performance. But then we would loose some of the gain.
>
> Thanks... Dominik.
>
>
> On Sun, Nov 22, 2009 at 10:31 PM, Bertrand Florat <ber...@fl...>wrote:
>
>> Fine, I'll have a look at profiling results to check the effects but this
>> kind of memory optimization is probably the way we need (FYI, I introduced
>> this kind of lazy loading for columns in table views in 1.7, it saved a
>> lot
>> of memory).
>>
>> Another idea : seems that string object have a significant memory overhead
>> in comparison with a char array. Maybe should be convert IDs to char[] ?
>>
>> On Sun, Nov 22, 2009 at 4:57 PM, Dominik Stadler <dom...@gm...
>> >wrote:
>>
>> > Hi,
>> >
>> > I just committed a change to use "lazy loading" in the Files Tree View.
>> > Memory analysis showed that we were using up quite some memory in there
>> > because all sub-nodes (and sub-sub-nodes, and ...)  were already loaded
>> > whenever the tree was displayed initially. Additionally the nodes kept
>> some
>> > more memory which I could also remove this way. Node Tree-Nodes are not
>> > created untill the parent-directory-node is expanded.
>> >
>> > Please let me know if I introduced any problem with this change, it does
>> > work fine for me so far.
>> >
>> > Also if you manage to do a quick check with something like jconsole and
>> let
>> > me know the difference in Java heap memory that you see before and after
>> > this change we can verify if this change is really reducing memory
>> usage.
>> >
>> > Thanks... Dominik.
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> > trial. Simplify your report design, integration and deployment - and
>> focus
>> > on
>> > what you do best, core application coding. Discover what's new with
>> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> > _______________________________________________
>> > Jajuk-developers mailing list
>> > Jaj...@li...
>> > https://lists.sourceforge.net/lists/listinfo/jajuk-developers
>> >
>>
>>
>>
>> --
>> Bertrand FLORAT
>> ber...@fl...
>> http://www.florat.net
>> PGP keyserver:  pgp.mit.edu
>> Try Jajuk Advanced jukebox (http://jajuk.info)
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Jajuk-developers mailing list
>> Jaj...@li...
>> https://lists.sourceforge.net/lists/listinfo/jajuk-developers
>>
>
>


-- 
Bertrand FLORAT
ber...@fl...
http://www.florat.net
PGP keyserver:  pgp.mit.edu
Try Jajuk Advanced jukebox (http://jajuk.info)