Optimize CodeHintList DOM build #3776
Conversation
…commit of code hint when pressing enter.
ghost
assigned 
| @@ -308,7 +328,7 @@ define(function (require, exports, module) { | |||
| } else if (this.selectedIndex !== -1 && | |||
| (keyCode === KeyEvent.DOM_VK_RETURN || keyCode === KeyEvent.DOM_VK_TAB)) { | |||
| // Trigger a click handler to commmit the selected item | |||
| $(this.$hintMenu.find("li")[this.selectedIndex]).triggerHandler("click"); | |||
| $(this.$hintMenu.find("li")[this.selectedIndex]).trigger("click"); | |||
There was a problem hiding this comment.
Reposting here as I was incorrectly commenting on the commit.
I'm not clear why this is more efficient than triggerHandler. I know that triggerHandlers do not bubble up the DOM hierarchy. So how can a trigger call be faster if it does propagation?
There was a problem hiding this comment.
Well, I think we're talking about different issues here.
On line 28 we create a single delegate event handler (which relies on event bubbling). Previously, we would install event handlers on each li. So, instead of taking the performance hit when building the DOM, we now have a negligible hit waiting for the event to bubble. So it's faster to load the code hints, but slightly slower to execute the code hint.
There was a problem hiding this comment.
Thanks for excellent explanation. Now I'm clear where you're improving the performance.
|
In my testing the new code seems to pop up code hints faster when I tried with js hinting. And selecting hint with Tab or Enter key doesn't seem to be slower even though we're using "trigger" call. So looks good. Merging. |
Optimize CodeHintList DOM build
litemplate generation, then add append jQuery content afterwards. When showing the full list of jQuery hints, elapsed time went from 51ms to 1msdata-attribute to store hint data forhandleSelectulinstead of individual event handlers for eachli