From: SourceForge.net <no...@so...> - 2007-04-04 10:22:25
|
Bugs item #1692397, was opened at 2007-04-01 17:25 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1692397&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 18. [text] Group: development: 8.5a6 Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: Csaba Nemethi (nemethi) Assigned to: Jeffrey Hobbs (hobbs) Summary: Poor text widget performance in Tk 8.5a6 Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2007-04-04 11:22 Message: 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. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2007-04-04 11:15 Message: 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). ---------------------------------------------------------------------- Comment By: Csaba Nemethi (nemethi) Date: 2007-04-03 22:21 Message: 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). ---------------------------------------------------------------------- Comment By: Csaba Nemethi (nemethi) Date: 2007-04-03 22:17 Message: 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). ---------------------------------------------------------------------- Comment By: Csaba Nemethi (nemethi) Date: 2007-04-03 20:13 Message: 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). ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2007-04-02 22:49 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1692397&group_id=12997 |