Community
Participate
Working Groups
Go to any browser and open a file in the editor. Hit ctrl j The initial text in the search fields reads: Intremental find: undefined It used to show nothing (empty string) which was much better. Now type something, nothing happens. Worse, the CPU is pegged (it seems). Quite some time after what you typed is shown.
In the latest code, incremental search seems to be working, although it does show "undefined" in the beginning before you type something
Which Browsers are you using ? I just tried IE and the problem is still there (I using the lastest client code). Note, when you get the chance to work in the incremental search please try to fix Bug 335604 along.
Mark can you investigate?
(In reply to comment #0) > The initial text in the search fields reads: > Intremental find: undefined This happened during the service refactoring, but it's just a visual problem. > Now type something, nothing happens. Worse, the CPU is pegged (it seems). > Quite some time after what you typed is shown. Our incremental find algorithm is bad. On every keypress, we're doing a global regexp search on the buffer to return all the matches. IE's Regex engine chokes on this when you have a large buffer with many matches. (I saw it performing about 300-800x slower than FF/Chrome). It's been like this since pre-M4.
> Our incremental find algorithm is bad. On every keypress, we're doing a global > regexp search on the buffer to return all the matches. IE's Regex engine chokes > on this when you have a large buffer with many matches. (I saw it performing > about 300-800x slower than FF/Chrome). It's been like this since pre-M4. I will fix this for simple (ie. non-regexp) searches. Using Ctrl+F to explicitly search for a regex like /./ in a huge buffer will still be slow, but the most common usecases will be fast, including incremental find.
(In reply to comment #5) > I will fix this for simple (ie. non-regexp) searches. Using Ctrl+F to > explicitly search for a regex like /./ in a huge buffer will still be slow, but > the most common usecases will be fast, including incremental find. I released a follow-up change that makes regex-find-next performant in IE. However, regex-find-previous is still slow, because it has to iterate past all matches up to the caret position. With a bad input regex and a large file, this can hang IE for a long time. Strangely, IE performs acceptably on the same input if hardcoded Regex literals are used. I thought that its engine would compile expressions created via the RegExp() constructor to the same form as literals, but apparently that's not the case here.
closing note: I suppose that every search starts with a call to editor.getText(). Note that this not optimal as internally the editor (text model in fact) stores the text using an array of strings. The editor has to join all the string elements in the array to return a single string object that represent the entire content. It means that for that moment we double the memory necessary to store the text. I believe that text search should be implemented at the text model level, so it can be performed without creating (too much) extra memory.
(In reply to comment #6) > However, regex-find-previous is still slow, because it has to iterate past all > matches up to the caret position. With a bad input regex and a large file, this > can hang IE for a long time. > > Strangely, IE performs acceptably on the same input if hardcoded Regex literals > are used. I thought that its engine would compile expressions created via the > RegExp() constructor to the same form as literals, but apparently that's not > the case here. It turns out that this is only a problem in IE8. IE9 performs acceptably (on par with Firefox) on the same input.
