On Sun, Mar 21, 2010 at 04:28, Ulf Zibis <ulf.zi...@gmx.de> wrote: > On Sat, Mar 20, 2010 at 17:13, Ulf Zibis <ulf.zi...@gmx.de> wrote:
> I don't think it's a performance problem in the real world. > > > Hm, if someone uses: > if (Character.isBMPCodePoint(codePoint)) > ...; > else if (Character.isSupplementaryCodePoint(codePoint)) // instead > isValidCodepoint() > ...; > else > ...; > he will loose up to 50 % performance as you can see on my benchmark on > isSuppCPAlaMartin(). Only if their data is full of supplementary characters. > We don't usually put such performance information in the javadoc. > > > In class StringBuilder: > "Where possible, it is recommended that this class be used in preference to > StringBuffer as it will be faster under most implementations." > > java.util.List: > Note that these operations may execute in time proportional to the index > value for some implementations (the LinkedList class, for example). > > ByteBuffer#get(byte[],int,int): > In other words, an invocation of this method of the form > src.get(dst, off, len) has exactly the same effect as the loop > > for (int i = off; i < off + len; i++) > dst[i] = src.get(); > > except that it first checks that there are sufficient bytes in this buffer > and it is potentially much more efficient. In the above, the performance is a Raison d'être of the API, that real users should consider when choosing API. > Anyway, even if isSupplementaryCodePoint() is used isolated, my code will > help JIT to use 2-byte shifted adressing and shorter 2-byte immediate value > for the compare, but yes, JIT should be able to catch that without this > help. But for that case, we could stay on the old implementations too for > isBMPCodePoint and is ValidCodePoint. Again, performance with BMP characters is infinitely more important than performance with supplementary characters. Martin