Bugzilla

ok, I did some profiling using the filter from comment 10 (615 OR conditions).

`filterEditorOnLoad` itself takes ~16 seconds.

The first ~12 seconds is spent in `initializeDialog` https://searchfox.org/comm-central/rev/461a63b4e564c1eabccc8dcba538b4cb11307f06/mailnews/search/content/searchTerm.js#193

~1 second to select all the text in `#filterName` https://searchfox.org/comm-central/rev/461a63b4e564c1eabccc8dcba538b4cb11307f06/mailnews/search/content/FilterEditor.js#199

~3 seconds to focus it https://searchfox.org/comm-central/rev/461a63b4e564c1eabccc8dcba538b4cb11307f06/mailnews/search/content/FilterEditor.js#201

The fact that selecting and focusing take so long suggests to me that the UI is bloated. Once the dialog is opened, resizing it is very laggy.

### initializeDialog

Each call to `createSearchRow` takes ~21ms. Almost all of this is in `<search-attribute>`'s `connectedCallback` https://searchfox.org/comm-central/source/mailnews/search/content/searchWidgets.js#518

Doing some digging I found that ~10ms is spent on this line alone https://searchfox.org/comm-central/rev/461a63b4e564c1eabccc8dcba538b4cb11307f06/mailnews/search/content/searchWidgets.js#724-821 . The stack trace is:

```
chrome://messenger/content/searchWidgets.js 724 connectedCallback
chrome://messenger/content/searchWidgets.js 378 set value/< (call to customElements.upgrade)
chrome://messenger/content/searchWidgets.js 377 set value
chrome://messenger/content/searchWidgets.js 462 refreshList
chrome://messenger/content/searchWidgets.js 653 set parentValue
chrome://messenger/content/searchWidgets.js 372 set value/<
chrome://messenger/content/searchWidgets.js 370 set value
chrome://messenger/content/searchWidgets.js 462 refreshList
chrome://messenger/content/searchWidgets.js 315 set searchScope
chrome://messenger/content/searchTerm.js 72 set searchScope
chrome://messenger/content/searchTerm.js 426 initializeTermFromIndex
chrome://messenger/content/searchTerm.js 420 initializeTermFromId
chrome://messenger/content/searchWidgets.js 520 connectedCallback
chrome://messenger/content/searchTerm.js 402 createSearchRow
chrome://messenger/content/searchTerm.js 196 initializeSearchRows
chrome://messenger/content/FilterEditor.js 403 initializeDialog
chrome://messenger/content/FilterEditor.js 96 filterEditorOnLoad
```

And about ~3ms is spent here https://searchfox.org/comm-central/rev/461a63b4e564c1eabccc8dcba538b4cb11307f06/mailnews/search/content/searchWidgets.js#1199-1205 (also called from `<search-value>`'s `connectedCallback`).

These are the most significant chunks of computation time I could find.

Note that most of this code (the use of custom elements) comes from bug 1534345.

Given all this, I think a switch to using html `<select>` elements, where possible, would help. And using `<select is="custom-select">`, rather than `<custom-select>`, if we still need custom classes.

ok, I did some profiling using the filter from comment 10 (615 OR conditions).

`filterEditorOnLoad` itself takes ~16 seconds.

The first ~12 seconds is spent in `initializeSearchRows` https://searchfox.org/comm-central/rev/461a63b4e564c1eabccc8dcba538b4cb11307f06/mailnews/search/content/searchTerm.js#193

~1 second to select all the text in `#filterName` https://searchfox.org/comm-central/rev/461a63b4e564c1eabccc8dcba538b4cb11307f06/mailnews/search/content/FilterEditor.js#199

~3 seconds to focus it https://searchfox.org/comm-central/rev/461a63b4e564c1eabccc8dcba538b4cb11307f06/mailnews/search/content/FilterEditor.js#201

The fact that selecting and focusing take so long suggests to me that the UI is bloated. Once the dialog is opened, resizing it is very laggy.

### initializeDialog

Each call to `createSearchRow` takes ~21ms. Almost all of this is in `<search-attribute>`'s `connectedCallback` https://searchfox.org/comm-central/source/mailnews/search/content/searchWidgets.js#518

Doing some digging I found that ~10ms is spent on this line alone https://searchfox.org/comm-central/rev/461a63b4e564c1eabccc8dcba538b4cb11307f06/mailnews/search/content/searchWidgets.js#724-821 . The stack trace is:

```
chrome://messenger/content/searchWidgets.js 724 connectedCallback
chrome://messenger/content/searchWidgets.js 378 set value/< (call to customElements.upgrade)
chrome://messenger/content/searchWidgets.js 377 set value
chrome://messenger/content/searchWidgets.js 462 refreshList
chrome://messenger/content/searchWidgets.js 653 set parentValue
chrome://messenger/content/searchWidgets.js 372 set value/<
chrome://messenger/content/searchWidgets.js 370 set value
chrome://messenger/content/searchWidgets.js 462 refreshList
chrome://messenger/content/searchWidgets.js 315 set searchScope
chrome://messenger/content/searchTerm.js 72 set searchScope
chrome://messenger/content/searchTerm.js 426 initializeTermFromIndex
chrome://messenger/content/searchTerm.js 420 initializeTermFromId
chrome://messenger/content/searchWidgets.js 520 connectedCallback
chrome://messenger/content/searchTerm.js 402 createSearchRow
chrome://messenger/content/searchTerm.js 196 initializeSearchRows
chrome://messenger/content/FilterEditor.js 403 initializeDialog
chrome://messenger/content/FilterEditor.js 96 filterEditorOnLoad
```

And about ~3ms is spent here https://searchfox.org/comm-central/rev/461a63b4e564c1eabccc8dcba538b4cb11307f06/mailnews/search/content/searchWidgets.js#1199-1205 (also called from `<search-value>`'s `connectedCallback`).

These are the most significant chunks of computation time I could find.

Note that most of this code (the use of custom elements) comes from bug 1534345.

Given all this, I think a switch to using html `<select>` elements, where possible, would help. And using `<select is="custom-select">`, rather than `<custom-select>`, if we still need custom classes.