(In reply to Denis Palmeiro [:denispal] from comment #5)
FWIW, I am able to reproduce what Andrew can see on ARM. I also was able to capture this with the tracelogger on ARM64 and most of our time is also spent in Baseline, which is good. However, I want to confirm again that the Ion events on x86 are not the main reason it's faster there. I also discussed the profile at the time with Bas, and he believes it's part of our implementation of sparse array dictionary objects which could be improved. I also tested this on Edge and they blow us out of the water when it comes to gdocs latency on ARM64. There's definitely room for improvement.
As I said, I am very interested in working with you on getting to the bottom of this, especially if Bas continues to think that there is room for improvement. I was able to get a profile on x86 on Ubuntu with a build from moz-central that contains jstrace results. Despite not knowing exactly what I am looking at, it seems that most of the time is spent in baseline but eventually some of the code ends up executing in Ion as we move further along.
For https://perfht.ml/2WSIekM, I turned the timing granularity higher than normal which is why (I think) there are so many calls to get the clock time (etc) and overall laginess. Again, running this test without the profiler shows no input latency at all.