Finn Bock wrote:
I would guess that doing ~6 string compares to navigate the binary
tree (with 148 color keywords) is slower than one string hash, ~1.2
int compares and one string compare. But I haven't measured it, so you
might be well be right. Many keyword sets for other properties are
[Finn Bock]
You should perhaps also be aware that the values
in a static array gets
assigned to the array one element at a time. So
static int[] a = {
101,102,103,104,105,106,107,108 };
becomes in bytecodes:
Method static {}
0 bipush 8
2 newarray int
4 dup
5 iconst_0
[Glen Mazza]
You should perhaps also be aware that the values in a static array
gets assigned to the array one element at a time. So
[J.Pietschmann]
That's an unpleasant surprise. I was always under the impression
statically initialized data was stored along with the string
constants, like in C. This means a
-Original Message-
From: Finn Bock [mailto:[EMAIL PROTECTED]
[ Glen : ]
Sigh...I guess I *didn't* know bytecode by heart after
all! ;-)
I didn't bring it up to discourage the use of static initialized arrays.
If it makes sense to put something in a static array we should do so
Finn Bock wrote:
I would guess that doing ~6 string compares to navigate the binary tree
(with 148 color keywords) is slower than one string hash, ~1.2 int
compares and one string compare. But I haven't measured it, so you might
be well be right. Many keyword sets for other properties are much
[Glen Mazza]
I've looked at your changes--I like them, and I'm
thankful to have someone on our team to be able to
redesign the properties as you have. Getting rid of
the 250 autogenerated or so classes will be a welcome
improvement.
But the biggest improvement is IMHO the easy ability to create
Glen Mazza wrote:
One thing that *does* stick out, however, is the 100
or so addKeyword() calls for genericColor
...
I'd like us to have a static array of these
values--i.e., something done compile-time, that
genericColor can just reference, so we don't have to
do this keyword initialization.
Finn Bock wrote:
You should perhaps also be aware that the values in a static array gets
assigned to the array one element at a time. So
That's an unpleasant surprise. I was always under the impression
statically initialized data was stored along with the string
constants, like in C. This means a
--- Finn Bock [EMAIL PROTECTED] wrote:
But the biggest improvement is IMHO the easy ability
to create special
maker subclasses to handle the corner cases. Take a
look at
IndentPropertyMaker for the calculation of start and
end-indent and at
BorderWidthPropertyMaker for the special
Finn Bock wrote:
I probably need an example of what you thinking are here. Right now in
HEAD all the color keywords are stored in a HashMap created in
GenericColor so the keywords initialization is already done. Putting the
keywords in static array would require us to somehow search the array
--- Peter B. West [EMAIL PROTECTED] wrote:
[Finn Bock]
You should perhaps also be aware that the values
in a static array gets
assigned to the array one element at a time. So
static int[] a = {
101,102,103,104,105,106,107,108 };
becomes in bytecodes:
Method static {}
11 matches
Mail list logo
