pptr-testing-library icon indicating copy to clipboard operation
pptr-testing-library copied to clipboard

don't send entire library on each evaluation

Open patrickhulce opened this issue 6 years ago • 5 comments

right now the entire dom-testing-library is sent on each evaluateAsync call to avoid execution context change problems (and global pollution), instead it could be installed just once on each page and reused through some sort of .install() mechanism or simple cached lookup

patrickhulce avatar Jun 29 '18 22:06 patrickhulce

Have you had any more thoughts on this performance enhancement? It seems rough that we send 150kb of JS on each lookup.

joeljeske avatar Jan 09 '20 22:01 joeljeske

Seemed rough to me too, yes, but empirical evidence from my usage of this library so far hasn't really run into this as a bottleneck yet.

Are you running into this as being particularly slow for your tests?

patrickhulce avatar Jan 10 '20 00:01 patrickhulce

Im seeing a significant slow down for each query compared to using page.$ or even page.evaluateHandler("document.querySelector()"). I know that raw selectors are not very comparable to getting by text but im not sure of another good way to compare times (ideas?)

Given a small-ish page with a <h1> tag, im seeing results like this:

evaluateHandle(document.querySelector): 0.687ms
page.$(h1): 2.942ms
getByText: 25.772ms

Whereas 25ms is not super slow on its own, it is an order of magnitude slower than page.$ and nearly 40 times slower than evaluateHandle.

I'd be curious how much of this could be sped up by somehow caching the evaluation on the browser side. It is of course possible that that the bulk of this time difference is just in the querying of the dom performed by dom-testing-library in which case we could not do much to fix it, but I'd like to determine that.

joeljeske avatar Jan 10 '20 01:01 joeljeske

getByText is not really a fair comparison to page.$(nodeType). I would be astonished if we were ever able to get it within an order of magnitude for any real world example when one requires examining all text nodes while the other is a browser-accelerated querySelector.

That aside, it's certainly possible to enable the single eval of the library and maybe cut that time in half or more. Its just more complicated than the current setup. Feel free to take a stab if you'd like.

patrickhulce avatar Jan 10 '20 04:01 patrickhulce

Also note that the first invocation wouldn't improve at all with this change, only subsequent invocations.

patrickhulce avatar Jan 10 '20 04:01 patrickhulce