Bug 559785

Summary:	Huge event leak in text editor
Product:	[Mono] MonoDevelop	Reporter:	Michael Hutchinson <mhutchinson>
Component:	texteditor	Assignee:	Michael Hutchinson <mhutchinson>
Status:	RESOLVED FIXED	QA Contact:	MD Bugs <monodevelop-bugs>
Severity:	Major
Priority:	P5 - None
Version:	SVN
Target Milestone:	---
Hardware:	x86
OS:	Mac OS X 10.6
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Michael Hutchinson 2009-12-02 05:05:32 UTC

There is a huge event leak in the text editor. This is partly because of Mono.TextEditor.DefaultStyle, which it recreated for every widget, and attaches itself to the StyleSet and Destroyed events of the widget, but only detaches when the widget is destroyed. It doesn't get detached when the editor's style is changed.

That's only part of the story. There are also far too many of these getting created. For example, with 13 editor tabs, applying MD prefs 5 times with the "default" style, I measured *8000* DefaultStyle objects attached to widgets. At the end, pressing "Ok" in the prefs dialog took *2 minutes* to apply changes because of all the attached style change events handlers.

* Far too many style objects are created and attached
* Attached styles are changed even when the user's selected editor style has not actually changed
* Styles are never detached


I suspect this is part of the unusual slowdown that has been affecting some of our Mac users - though there must be something else involved. A few reasons:
* I discovered this following kill -QUIT traces from 2 users affected by the slowdown.
* Another user reported that the slowdown temporarily goes away when an editor tab is closed, which would be explained by the styles detaching when the widget is destroyed

I suspect users are hitting some kind of style propagation feedback loop, or a style change somehow triggered by keystrokes/editing - which is being greatly exacerbated by this issue.

Comment 1 Michael Hutchinson 2009-12-02 05:07:17 UTC

Note that the MonoDevelop.Ide.FindInFiles.SearchResultWidget also creates one of these on *every* cell render.

Comment 2 Michael Hutchinson 2009-12-02 05:24:13 UTC

This also appears to be the cause of the search slowdown that Alan reported the other day.

MonoDevelop.SourceEditor.SearchAndReplaceWidget.StoreHistory causes the property service to send change events for *ALL* prefs, then every DefaultSourceEditorOptions updates each child option, and each child options causes every text editor instance to update all its settings from the SourceEditorOptions, including a syntax scheme change, which sets the widget's bg colour, which broadcasts to all the thousands of default styles.

In other words:

changing any one property on the property service
=>
every text editor's DefaultSourceEditorOptions gets updated
=>
updates all its properties, each of these emits a change event
=>
text editor updates its syntax style, updates its own GTK+ style
=>
style change event is broadcast to the thousands of event handlers that have accumulated

This is fail on every level.

Comment 3 Michael Hutchinson 2009-12-02 05:25:03 UTC

I'll fix this.

Comment 4 Michael Hutchinson 2009-12-02 08:09:08 UTC

OK, I think I nailed it. Made closing the prefs dialog *much* faster too.

Comment 5 Michael Hutchinson 2009-12-02 08:15:47 UTC

The bug with the trace is Bug 543956. The problem seems to be triggered by CSharpTextEditorIndentation.KeyPress calling TextEditorProperties.get_IndentStyle ()  which called PropertyService.Set and set off the massive, leaky, indiscriminate change broadcast detailed above.