Re: svn commit: r882137

[Greg Brown <gk...@mac.com>]

> That's a good idea - it also get around the problem that the array elements
> are currently mutable, when we intend for them to be final.  Yeah, go ahead
> and create a ticket for 1.4.1.

I'm not entirely sure what the context is for this suggestion, but I think that bit sets are also mutable, so they may not offer that much of an advantage here.

Re: svn commit: r882137

[Todd Volkert <tv...@gmail.com>]

I realized after I sent this that I'd change the Metadata class to provide
accessor methods instead of direct access to the field anyway :)

-T

On Thu, Nov 19, 2009 at 8:46 AM, Greg Brown <gk...@mac.com> wrote:

> > That's a good idea - it also get around the problem that the array
> elements
> > are currently mutable, when we intend for them to be final.  Yeah, go
> ahead
> > and create a ticket for 1.4.1.
>
> I'm not entirely sure what the context is for this suggestion, but I think
> that bit sets are also mutable, so they may not offer that much of an
> advantage here.
>
>

Re: svn commit: r882137

[Greg Brown <gk...@mac.com>]

> a boolean uses 1 byte, while in a BitSet every value inside is stored
> as a single bit (plus the overhead of the data structure), so with
> many rows the difference could be visible, but I agree that with
> modern PC a few MB is not so much ... but if the effort is not too
> much (and at low priority) why not do it ?

That is true, but GridPane isn't meant to be used with thousands of rows of data. That is what TableView is for.

Re: svn commit: r882137

[Sandro Martini <sa...@gmail.com>]

On this I'm thinking on a Component containing many (some thousand)
records (like a Table or a Tree), because in all other cases this
doesn't makes so much difference, I agree.

If this is not applied, be free to change the ticket to won't fix, or
tell me ...

Sandro

Re: svn commit: r882137

[Todd Volkert <tv...@gmail.com>]

Keep in mind that we're talking about grid pane, which is a container and
not likely to contain more than ... 10 ... 100 ... rows & columns?  So we're
talking about using at most 100 bytes in an array vs whatever the BitSet
class will take up.  The array is actually likely to run faster, because
indexed memory access is O(1), but either way, we're talking about
nanoseconds, if that.

I was more concerned with the immutability of the data, but that's been
addressed another way, so I'm less enthusiastic about this change now :-/

-T

On Thu, Nov 19, 2009 at 9:26 AM, Sandro Martini <sa...@gmail.com>wrote:

> Ah, a last thing:
> a boolean uses 1 byte, while in a BitSet every value inside is stored
> as a single bit (plus the overhead of the data structure), so with
> many rows the difference could be visible, but I agree that with
> modern PC a few MB is not so much ... but if the effort is not too
> much (and at low priority) why not do it ?
>
> Bye
>

Re: svn commit: r882137

[Sandro Martini <sa...@gmail.com>]

Ah, a last thing:
a boolean uses 1 byte, while in a BitSet every value inside is stored
as a single bit (plus the overhead of the data structure), so with
many rows the difference could be visible, but I agree that with
modern PC a few MB is not so much ... but if the effort is not too
much (and at low priority) why not do it ?

Bye

Re: svn commit: r882137

[Sandro Martini <sa...@gmail.com>]

> True, but it is such a minor optimization that any improvement would probably never even be noticeable.
Ok, but if possible I'd keep this, and see later what to do, Ok ?
Having a growable data structure like this could also be useful when
adding additional rows to a table (like fetching the next page of
records) instead of reallocate (by hand) the array.

I'd like to see the difference on tables with some thousand of rows,
and many columns ...

Bye

Re: svn commit: r882137

[Greg Brown <gk...@mac.com>]

True, but it is such a minor optimization that any improvement would probably never even be noticeable.


On Nov 19, 2009, at 9:07 AM, Sandro Martini wrote:

> Oh, sorry, just read this mail ... but if not for immutable status I
> think this could be useful for the memory (less) usage.
> 
> Sandro

Re: svn commit: r882137

[Sandro Martini <sa...@gmail.com>]

Oh, sorry, just read this mail ... but if not for immutable status I
think this could be useful for the memory (less) usage.

Sandro