Artur Biesiadowski <[EMAIL PROTECTED]> writes:
> I still think that major penalty is creation of CharAttr for every
> request. It is really overhead, as it is never reused. I think that if
> all methods would access table directly and lookup only what is needed,
> we could match JDK speed (be not
>Now, there is no more file access at runtime and results are better, but
>still very bad. Speedup for dropping file access was 3x, not 20x. My
>test has changed, so here are updated results (all JDK1.1.5, Tya 1.2,
>given in ms)
You found my updated version I take it? I will look at other perfor
Paul Fisher wrote:
[...]
> Things could be optimized to assume that once you've asked for data
> about a specific character, it's likely that you'll ask for more data
> on that same character. Such a change should incur a 20x performance
> increase for your test.
>
> Yet another option is to sti
Paul Fisher <[EMAIL PROTECTED]> writes:
> Wes Biggs <[EMAIL PROTECTED]> writes:
>
> > Is there an elegant way to make this configurable at compile or
> > runtime?
>
> Assuming we start using a preprocessor, it should be easily
> configurable at compile time.
>
> Brian, you want to get GNU cccp
Wes Biggs <[EMAIL PROTECTED]> writes:
> Is there an elegant way to make this configurable at compile or
> runtime?
Assuming we start using a preprocessor, it should be easily
configurable at compile time.
Brian, you want to get GNU cccp working with the build setup? :)
> I'm not an expert on h
Paul Fisher wrote:
> Yet another option is to stick the entire Unicode attribute database
> into memory -- it's around 21k.
I think the majority of users would be willing to pay for the 21k (which is
probably far less than the JDK code requires thanks to your smart packing
scheme). Is there an
Paul Fisher <[EMAIL PROTECTED]> writes:
> Such a change should incur a 20x performance increase for your test.
Actually, it would be 20x faster for each character tested...so things
should go much quicker. We'd be eliminating 1,310,720 disk accesses,
overall.
Hmm... that's a lot of disk access
Artur Biesiadowski <[EMAIL PROTECTED]> writes:
> 1) isWhiteSpace should be isWhitespace
Fixed.
> 2) readChar should not return null on not-defined characters.
I'll look into this.
> 3) There is no need for putting char ch field in CharAttr - it is not
> used anywhere
I'll look into this.
>
From: Artur Biesiadowski <[EMAIL PROTECTED]>
>I have done extensive test on java.lang.Character class. Here are my
>conclusions:
Thanks for the report.
>5) Performance is terrible. Terrible squared. Slower than slow. Here are
>the benchmark results
I believe the Classpath Character class relies
I have done extensive test on java.lang.Character class. Here are my
conclusions:
1) isWhiteSpace should be isWhitespace
2) readChar should not return null on not-defined characters. There
should be something like:
if ( block == -1 ) return CharAttr(ch,false,UNASSIGNED,-1,ch,ch);
or
10 matches
Mail list logo
