1288613 - Implement Cache for improving performance of ContentEventHandler

Status: NEW

(Core :: DOM: UI Events & Focus Handling, enhancement, P3)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

As we know, ContentEventHandler is very slow with big offset in HTML editor.

So, I'm now thinking about how to improve it.

Current my idea is, we should create ContentEventHandler::Cache as a nested class. It has an array whose item is:

class Item final
{
  friend class ContentEventHandler;
  friend class ContentEventHandler::Cache;

private:
  // A node causing text
  nsIContent* mContent;
  // Generated text
  uint32_t mLength;

public:
  nsIContent* Content() const { return mContent; }
  uint32_t Length() const { return mLength; }
};

And the cache class is like:

class Cache final
{
private:
  nsTArray<Item> mItems;

  struct HistoryItem final
  {
    // index of the item
    size_t mIndex;
    // offset of the item
    uint32_t mOffset;
  };
  // When ContentEventHandler computes a offset, the index and offset are
  // stored to mHistory. Then, next query can skip to compute before the
  // computed offset.
  nsTArray<HistoryItem> mHistory;
};

If it's possible to cache this case in IMEContentObserver, we might be able to improve the performance of multiple query content event handlers, but I'm not sure we can do that with enough simple code.

If you have better idea about cache mechanism, let me know.
# I'm thinking that I could work on this in Q4.

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Masayuki, are you planning to resume this work soon?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I'd like to do that as soon as possible, however, the priority isn't so high in my queue.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Resetting assignee which I don't work on in this several months.