Menu
▾
▴
#2236 Poor text widget performance in Tk 8.5a6
open-wont-fix
5
2007-04-03
2007-04-01
No
The following simple script demonstrates a siginificant text widget performance regression in Tk 8.5a6:
pack [text .t]
puts [time {
for {set n 1} {$n <= 100000} {incr n} {
.t insert end "This is line #$n\n"
}
}]
On my rather slow Linux box (running SuSE Linux 10.0), this script produces the output
1580878 microseconds per iteration
Compare this with the time needed by Tk 8.4.13:
1238126 microseconds per iteration
This is a rather worrying performance regression, especially taking into account that the text widget implementation has been objectified in Tk 8.5.
Discussion
Logged In: YES
user_id=72656
Originator: NO
The text widget also supports peers and has several new enhanced features. I'm not sure that losing a fraction of a second for adding 100K lines is actually a "worrying" regression.
Logged In: YES
user_id=317958
Originator: YES
I have just repeated the test after a reboot. The new results are even worse than the ones contained in my original bug report:
wish8.4.13:
1067659 microseconds per iteration
wish8.5a6:
1584955 microseconds per iteration
You see this as "a fraction of a second". However, at the same time it is a performace regression by 48%! The new (great) features of the text widget do surely cause some performance penalty, which, however, should be quite minimal compared to the speed improvement normally gained by objectifying the implementation. For this reason, I suspect that the problem is not in the text widget stuff itself, but somewhere else.
Together with this bug report I submitted another one, related to the performance of the listbox widget. In the case of the listbox, the performance regression is nearly 60%! I am not aware of any significant changes in the listbox implementation, hence I wonder, what could be the reason for that really huge loss of speed.
Given that two of the most important Tk core widgets exhibit quite significant performance problems in Tk 8.5.a6, I think that there is something wrong at some other, central place in the Tk 8.5a6 code. Please note that these problems were not present in Tk 8.5a1 - 8.5a4 (I'm not sure about Tk 8.5a5, because I don't have that version).
Logged In: YES
user_id=317958
Originator: YES
I have just repeated the test after a reboot. The new results are even worse than the ones contained in my original bug report:
wish8.4.13:
1067659 microseconds per iteration
wish8.5a6:
1584955 microseconds per iteration
You see this as "a fraction of a second". However, at the same time it is a performace regression by 48%! The new (great) features of the text widget do surely cause some performance penalty, which, however, should be quite minimal compared to the speed improvement normally gained by objectifying the implementation. For this reason, I suspect that the problem is not in the text widget stuff itself, but somewhere else.
Together with this bug report I submitted another one, related to the performance of the listbox widget. In the case of the listbox, the performance regression is nearly 60%! I am not aware of any significant changes in the listbox implementation, hence I wonder, what could be the reason for that really huge loss of speed.
Given that two of the most important Tk core widgets exhibit quite significant performance problems in Tk 8.5.a6, I think that there is something wrong at some other, central place in the Tk 8.5a6 code. Please note that these problems were not present in Tk 8.5a1 - 8.5a4 (I'm not sure about Tk 8.5a5, because I don't have that version).
Logged In: YES
user_id=317958
Originator: YES
I have just repeated the test after a reboot. The new results are even worse than the ones contained in my original bug report:
wish8.4.13:
1067659 microseconds per iteration
wish8.5a6:
1584955 microseconds per iteration
You see this as "a fraction of a second". However, at the same time it is a performace regression by 48%! The new (great) features of the text widget do surely cause some performance penalty, which, however, should be quite minimal compared to the speed improvement normally gained by objectifying the implementation. For this reason, I suspect that the problem is not in the text widget stuff itself, but somewhere else.
Together with this bug report I submitted another one, related to the performance of the listbox widget. In the case of the listbox, the performance regression is nearly 60%! I am not aware of any significant changes in the listbox implementation, hence I wonder, what could be the reason for that really huge loss of speed.
Given that two of the most important Tk core widgets exhibit quite significant performance problems in Tk 8.5.a6, I think that there is something wrong at some other, central place in the Tk 8.5a6 code. Please note that these problems were not present in Tk 8.5a1 - 8.5a4 (I'm not sure about Tk 8.5a5, because I don't have that version).
Logged In: YES
user_id=79902
Originator: NO
Right now, we don't know enough information about the build configurations that you used to be able to work out whether it is a problem that impacts production code. For example, debugging builds are known to be quite a lot slower than optimized builds (and that's something that's caught me out quite a few times). We also don't know whether the problem is caused by system memory allocator changes; they could hit hard. The best way of testing that is to see if the results are replicatable on other platforms.
Another possible source of trouble might be the new antialiased font renderer; if that's much slower at measuring text width in 8.5, that would certainly hit us (e.g. the listbox code always measures the width of what is inserted despite being fundamentally the same code in 8.4 and 8.5; it's much harder to do the same comparison for the text widget though as that really is a wholly new implementation).
Logged In: YES
user_id=79902
Originator: NO
FWIW, unscientific testing (with your sample code) with ActiveTcl 8.4.14.0 and 8.5.0.0-beta5 on WinXP-SP2 got the following:
8.4: 755483 microseconds per iteration
8.5: 865871 microseconds per iteration
I don't know how comparable these values are, but I still suspect that there is some slowdown between those specific versions.
Logged In: YES
user_id=317958
Originator: YES
Donal, many thanks for your comments.
I used a normal, non-debugging build for the performance tests. Also, as mentioned in my last comment, the reported slowdown was not present in Tk 8.5a1 - 8.5a4. I don't have Tk 8.5a5, but I thoroughly suspect that that version was still OK with respect to the listbox and text widget performance. For this reason, I don't think that your testing with ActiveTcl 8.5.0.0-beta5 (which is based on Tcl/Tk 8.5a5) could bring us any further on the way towards finding out what is wrong.
I think you are right in your theory that the problem might be caused by changes related to the fonts. Tk 8.5a6 uses the Xft library, which could cause a quite significant slow-down. If this is the reason of the performace regression then the Windows version of Tk 8.5a6 should be free from the problem (I don't have any Tk 8.5aX version for Windows myself).
Logged In: YES
user_id=317958
Originator: YES
I have rebuilt Tk 8.5a6, using --enable-xft=no. Unfortunately, the slight performance improvement achieved by this change is not even worth mentioning. That is, contrary to what I was hoping, the problem is not caused by the use of the Xft library.
There must be something else wrong in Tk 8.5a6 (or maybe Tcl 8.5a6).
Logged In: YES
user_id=317958
Originator: YES
As already reported, deactivating the use of Xft doesn't improve the performance of the text widget. Now I repeated the performance test for the listbox and found that there the situation is different: With Xft the performance regression was nearly 60%; without Xft it is only about 11%.
This seems to confirm Donal's theory regarding the use of Xft in the case of the listbox widget. On the other hand, the text widget's performance regression is nearly 50%, regardless of whether the Xft library is being used or not.