You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey! Thank you for this library! It is very promising and I put a lot of hope into it, as JSDOM is super slow 😄
I was attempting to use it my project a while ago, but there were some issues that were blocking me from migrating from JSDOM. I noticed today your recent releases and decided to give it a try once again.
While most of the issues I have seen are fixed, I noticed that the performance is much worse after upgrading to any version >= 7.0.0. It's hard to make a reproducible example, but I had a test, quite heave one, that in the version 6.x of happy-dom was running in a 1-2 seconds. However, after updating to recent version I see it now taking around 10 seconds 🤯
The issue seems to be related to some of the new code added for better CSS support. I took some CPU snapshots of the same test running on different happy-dom versions.
v6.x:
v7.4.0:
On the second screenshot, most of top items (matchesClass, SeelctorItem, matches, etc...) are coming from happy-dom.
I tried looking at the code for this, but would need to spend much more time to get familiar myself with it, so I decided to first let you know. Do you think there is a chance to improve performance here?
As a temporary solution, I was thinking maybe there would be possibility to skip those CSS changes that are coming from v7.0.0 by setting some flag or something. In most tests I don't need full CSS support (and I assume it might be the same for most cases in general), so enabling it only when needed seems like a acceptable workaround. If it is possible to even add this as a config.
Thank you for help and, again, for your work on this great library! :) Please let me know if you'd need any more details from me.
The text was updated successfully, but these errors were encountered:
…ng a cache that is based on whenever the DOM tree changes. Improves Element.matches() to work with selectors of parent elements. Adds support for CSS rule priority to window.getComputedStyle().
window.getComputedStyle() is a very heavy operation as it has to parse style rules in all applicable Stylesheets.
I am not sure how window.getComputedStyle() is used in your code. It is a live object which is calculated whenever you access a property. It is also used by the Element.innerText property, as it returns the rendered text, which is based on style rules.
I have added support for a cache to window.getComputedStyle() that is based on updates to the DOM tree (appendChild(), removeChild() etc.). Hopefully this will solve the performance problems for you.
A solution for disabling the parsing is to remove all <style> and <link rel="stylesheet"> elements. Another solution is to override getComputedStyle() with window.getComputedStyle = () => new CSSStyleDeclaration();
Feel free to re-open this ticket if the problem hasn't been resolved.
Hey! Thank you for this library! It is very promising and I put a lot of hope into it, as JSDOM is super slow 😄
I was attempting to use it my project a while ago, but there were some issues that were blocking me from migrating from JSDOM. I noticed today your recent releases and decided to give it a try once again.
While most of the issues I have seen are fixed, I noticed that the performance is much worse after upgrading to any version >= 7.0.0. It's hard to make a reproducible example, but I had a test, quite heave one, that in the version 6.x of happy-dom was running in a 1-2 seconds. However, after updating to recent version I see it now taking around 10 seconds 🤯
The issue seems to be related to some of the new code added for better CSS support. I took some CPU snapshots of the same test running on different happy-dom versions.
v6.x:
v7.4.0:
On the second screenshot, most of top items (
matchesClass
,SeelctorItem
,matches
, etc...) are coming from happy-dom.I tried looking at the code for this, but would need to spend much more time to get familiar myself with it, so I decided to first let you know. Do you think there is a chance to improve performance here?
As a temporary solution, I was thinking maybe there would be possibility to skip those CSS changes that are coming from v7.0.0 by setting some flag or something. In most tests I don't need full CSS support (and I assume it might be the same for most cases in general), so enabling it only when needed seems like a acceptable workaround. If it is possible to even add this as a config.
Thank you for help and, again, for your work on this great library! :) Please let me know if you'd need any more details from me.
The text was updated successfully, but these errors were encountered: