Firefox is slow in creating Annotator instances

[tanius]

While in Chrome there is no noticeable difference when creating Annotator instances (without any annotations in them) for 30 fields on one page, Firefox might take 15-20 s of high CPU load to process this, until becoming responsive again (system: Core i7 2 GHz). So this is an issue of the slower JavaScript engine in Firefox – it is much slower in some functions, and instantiating Annotator seems to rely heavily on some of these.

Solution proposals, by current degree of favouring them:

1. Paging comments. In the most frequent case of annotating node and comment body fields, paging comments to 15 per page would help. An AJAX pager could be used to switch between them. Simple and effective. Optionally, paging comments would only be done for users where Annotator is active, if there is a way to configure such behavior.
2. Loading comments on demand. Like paging comments, but nicer: without the pages and with auto-loading when reaching the end of the page.
3. Delays, interruptions or other time for instantiating Annotators. Annotator has code to keep the browser responsive while loading annotations. Maybe something similar can be used here.
4. Loading annotators on demand. The events to create Aannotator instances would not be fired all at page load time, but only when the respective content first gets viewed. But with this, scrolling through a page with many comments fast would still lead to 10+ seconds of unresponsiveness.
5. Removing the bottleneck. Finding the bottleneck would be simple with a JS profiler, but removing it might or might not be simple …
6. Using Annotator 2.0. A quick look does not indicate if multi-instance resource usage is handled better in the 2.0 version [codepoint] than in the 1.2.9 version [codepoint]. But it could well be, and is worth a try. Version 2.0 is expected in early 2015 [source], and since it is in feature freeze, it could be used already. However a major rework of the annotator and annotation Drupal plugins is required to get it to work. Also, third-party Annotator plugins will not support 2.0 initially, but that is less of a problem as we only use Annotator core plugins (Tags, Store, Permissions) and these are mostly supported.
7. Not supporting Firefox. But telling users to use Chrome / Chromium is not really an option.

Hints for debugging:

• Annotator instances are stored in the Annotator._instances JavaScript array.
• You can check if your jQuery selector is fine by executing the following in your browser's JavaScript console, on a typical page you want to annotate: jQuery("insert-your-selector").size() == 1
• Multiple instances slow down the time until the page is fully loaded (not though until something is displayed). This is because of multiple calls to /annotation/api/search. This is cared for in #42 already.

[tanius]

Initial profiling results:

• Chromium 39.0, jQuery 1.9.1, 8 Annotator instances: 801 ms (63% of 1,270 ms CPU time) for jQuery's curCSS function
• Firefox 35.0, jQuery 1.9.1, 8 Annotator instances: 8660 ms (42% of 20,500 ms CPU time) for jQuery's curCSS function :(
• Firefox 35.0, jQuery 1.10.2, 8 Annotator instances: 6616 ms (38% of 17,300 ms CPU time) for jQuery's curCSS function :(

All of the above curCSS calls are due to a single line of Annotator code in Annotator._setupDynamicStyle, namely annotator.coffee:160:

max = Util.maxZIndex($(document.body).find(sel))

This is used to find the maximum z index used in the page, in order to make Annotator display above it. For a known environment like Drupal, this is surely not worth 40% of execution time, so let's get rid of this.

(Hint: The internal profiler in Firefox often does not work properly, and the Firebug integrated profiler cannot be set active before page load. However, in this case it is enough to activate it once the first part of the page arrives.)

[tanius]

Profiling results after the change proposed above, on the same test page:

• Firefox 35.0, jQuery 1.10.2, 8 Annotator instances: 442 ms (8% of 5500 ms CPU time) for jQuery's curCSS function :)

Total JavaScript execution time is now 68% less / 3x faster. That should suffice! Also, the remaining JavaScript functions do not noticably interfere with Firefox responsiveness to user input.

[tanius]

Fixed for now. Remaining work: find a cleaner solution. See the code comment from the last commit.

[tanius]

This problem still is very noticeable with Firefox when visiting group index pages (where all the group's posts etc. are listed on the bottom). Esp. when the group has a lot of content. Not sure how that happens, maybe this "Commons group browsing widget" only shows the first page but pre-loads all pages in the pages in the background, which would entail creating Annotator instances on all of them, too.

To be fixes when there is some time for it, since so far nobody except me complained.

[albertocottica]

Chrome is slow too. I think this is not so serious, because normal users of ER are not affected, and researchers need time to think anyway. That leaves us (site admins): we normally do not code, and spend a lot of time on the platform.

Two workarounds that I can think of. Both involve Drupal permissions management. The first one goes as follows

1. Create a new role "Ethnographer", with permission to create annotations, edit and delete own annotations, view all annotations; create, view and edit and delete own taxonomy terms of vocabulary Open Ethnographer.
2. Create a new role "Ethnographer admin", with permissions as above + edit and delete any annotation and any taxonomy term of vocabulary Open Ethnographer.
3. Remove such authorizations from the site admin and content manager role.

The second workaround:

1. Create a new role "Ethnographer", with permission to create annotations, edit and delete own annotations, view all annotations; create, view and edit and delete own taxonomy terms of vocabulary Open Ethnographer.
2. Remove such authorizations from the content manager role.
3. Create new accounts with admin power for us, to use only when admin powers are needed.
4. Downgrade our present accounts (Alberto, Noemi etc.) to content manager.

Both workarounds can be implemented simply from the Drupal admin interface, no coding involved.

@tanius what do you think?

[tanius]

These workaround would work, yes … yet if the speed issue is only about the group browsing widgets now, it seems cleaner to modify them (loading all content in the background is no good idea anyway). After all, the current set of optimizations should make OpenEthnographer closer to be usable by everyone else as well, so it makes sense to invest a bit more than what's needed for workarounds.

Another option is a user profile option where every user with access to OE can choose if they want it loaded or not.