1 Nov 13:11
Re: thinlet using vectors
mike_hartshorn2 <mike_hartshorn <at> hotmail.com>
2004-11-01 12:11:11 GMT
2004-11-01 12:11:11 GMT
Hi Campbell, > Thanks for the patch link. I confirm that the patch eliminates the > JVM crash for huge lists regarding the tree control (and presumably > all other previous linked list type access patterns in Thinlet). > > So, for me, your patch is the start of A GoodThing(tm). Glad the patch proved useful for you. My main goal in the approach to this problem was to have a minimal patch that could be applied to future versions of thinlet, with very little pain. I really need to be able to display tables/trees that will occasionally be in the 1-2000 element size. I'd like to think that we can get some sort of fix in place for this, but appreciate that this approach might not be to everyone's taste (although it does coexist with the original implementation) and so might not end up in the core thinlet. > But, as you have stated, the patch needs some refinements: > > And here's a first... > > The symptom I'm seeing with your patch (that I do not see with the > original code) is that as one scrolls down further > ... > then scrolling gets slower and slower, until the delay becomes > completely unmanagable. Thanks for providing the modifications to avoid the exeception handling. I'd observed that this was happening but it hadn't occurred to me that it was happening so much. I still note that 'big' tables scroll slower towards the end (although much improved with your changes) and wonder if there is some linear search to find displayed region going on. Loading big lists/trees/tables etc, still takes longer than I'd like (due to grow/copy cycles in the Vector). I found checking for the existence of a property (say childcount=2000) and using that as a hint to preallocate the Vector really helped here. A 100k row table, still takes several minutes to load with the current code, if you preallocate the Vector it loads in about 5 seconds (We can discuss the utility of being able to handle such big tables, but 1) its useful for understanding the behaviour of thinlet and 2) its kind of neat
) The main issue with the current approach is the use of the ":slot" marker, to record your position in your parents ":children" list. In the tree manipulation code (and some other places) you need to be able to reference your parent's next object. As the objects are all in an array now (managed by the Vector), you can't store a direct reference to the object (as java will only let you store a reference to the start of an array - and its this nesting that causes the VM crash in the first place). This was the only satisfactory way I could think of getting round this problem. Any thoughts? Cheers, Mike ------------------------ Yahoo! Groups Sponsor --------------------~--> $9.95 domain names from Yahoo!. Register anything. http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM --------------------------------------------------------------------~->
.
Glad the patch proved useful for you.
My main goal in the approach to this problem was
to have a minimal patch that could be applied to
future versions of thinlet, with very little pain.
I really need to be able to display tables/trees
that will occasionally be in the 1-2000 element size.
I'd like to think that we can get some sort of fix
in place for this, but appreciate that this approach
might not be to everyone's taste (although it does
coexist with the original implementation) and so
might not end up in the core thinlet.
> But, as you have stated, the patch needs some refinements:
>
> And here's a first...
>
> The symptom I'm seeing with your patch (that I do not see with the
> original code) is that as one scrolls down further
> ...
> then scrolling gets slower and slower, until the delay becomes
> completely unmanagable.
Thanks for providing the modifications to avoid the
exeception handling. I'd observed that this was
happening but it hadn't occurred to me that
it was happening so much.
I still note that 'big' tables scroll slower towards
the end (although much improved with your changes)
and wonder if there is some linear search to find
displayed region going on.
Loading big lists/trees/tables etc, still takes
longer than I'd like (due to grow/copy cycles
in the Vector). I found checking for the
existence of a property (say childcount=2000)
and using that as a hint to preallocate the
Vector really helped here. A 100k row table,
still takes several minutes to load with the
current code, if you preallocate the Vector it
loads in about 5 seconds (We can discuss the
utility of being able to handle such big tables,
but
1) its useful for understanding the behaviour
of thinlet and
2) its kind of neat
)
The main issue with the current approach is
the use of the ":slot" marker, to record
your position in your parents ":children" list.
In the tree manipulation code (and some other
places) you need to be able to reference your
parent's next object. As the objects are all
in an array now (managed by the Vector), you
can't store a direct reference to the object
(as java will only let you store a reference
to the start of an array - and its this
nesting that causes the VM crash in the
first place). This was the only satisfactory
way I could think of getting round this problem.
Any thoughts?
Cheers,
Mike
------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
RSS Feed