The performance of the charsWidth method is quite poor, and the semantics are probably wrong as well. The specs note that the width of a String is not necessarily the same as the sum of the width of the characters, yet that appears to be how we currently determine it. The testcase attached shows the performance of our implementation versus the JDK on 100000 lines of text. Approximate results are 0.3 seconds for them, 25 seconds for us. charsWidth is quite often in swing.text painting and sizing and this can be quite a problem with large amounts of text.
Created attachment 9971 [details] testcase to demonstrate the bug
Yeah, I looked into this with the Qt peers and using stringWidth (which is implemented directly in native), although the difference versus using charsWidth wasn't really signficiant. I don't think this is a signficant bug. The benchmark test does 100,000 runs of strings which are rather short. On my machine the run took about 24 seconds with the Qt peers and jamvm. Out of that, about 0.5 seconds were spent on the JNI call, one second on converting the input to native, and the rest spent in the actual toolkit fontmetric method. This cannot be improved upon substantially. On the other hand, I don't feel this is slow. 24 seconds for 100,000 strings means an average of 0.24 microseconds per string. This is microoptimization. It's hard to improve on such a small number. Is it really needed? E.g. how many strings to you have on-screen at any time? I'd say about a hundred, taking 24 milliseconds to layout the text isn't a problem.
Subject: Re: FontMetrics charsWidth performance Sven, I believe you're right. Furthermore, the huge delays that we were seeing in Swing text turned out to be a problem with the parameters we were passing to this method, rather than the method itself, as I reported on IRC. Roman has said that this charsWidth is used a lot in Swing text painting, so if any optimizations are possible it would help, but it's not as important as I thought it was when I reported this bug. I think having more than 100 strings on screen is quite reasonable though, if you were running a small text editor, or jEdit or something like that. --Tony On Fri, 2005-10-14 at 21:53 +0000, sven at physto dot se wrote: > > ------- Comment #2 from sven at physto dot se 2005-10-14 21:53 ------- > Yeah, I looked into this with the Qt peers and using stringWidth (which is > implemented directly in native), although the difference versus using > charsWidth wasn't really signficiant. > > I don't think this is a signficant bug. The benchmark test does 100,000 runs of > strings which are rather short. On my machine the run took about 24 seconds > with the Qt peers and jamvm. Out of that, about 0.5 seconds were spent on the > JNI call, one second on converting the input to native, and the rest spent in > the actual toolkit fontmetric method. This cannot be improved upon > substantially. > > On the other hand, I don't feel this is slow. 24 seconds for 100,000 strings > means an average of 0.24 microseconds per string. This is microoptimization. > It's hard to improve on such a small number. Is it really needed? E.g. how many > strings to you have on-screen at any time? I'd say about a hundred, taking 24 > milliseconds to layout the text isn't a problem. > >