WARNING: THIS SITE IS A MIRROR OF GITHUB.COM / IT CANNOT LOGIN OR REGISTER ACCOUNTS / THE CONTENTS ARE PROVIDED AS-IS / THIS SITE ASSUMES NO RESPONSIBILITY FOR ANY DISPLAYED CONTENT OR LINKS / IF YOU FOUND SOMETHING MAY NOT GOOD FOR EVERYONE, CONTACT ADMIN AT ilovescratch@foxmail.com
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
In the process of upgrading G from v4 to v6, the underlying layer of G has been refactored a lot, from a single engine that only provides basic rendering capabilities to a plug-in engine, enriching a lot of ecological capabilities.
Unfortunately, performance issues were not paid close attention to during this process, resulting in a serious regression of performance benchmarks. So far, we have made a lot of efforts to optimize performance, but the results are still not ideal. The root cause is that our current strategy is relatively conservative. If we want to really improve performance, we need to make some adjustments to the current architecture. Considering the developer experience and maintenance costs, this is based on the premise that there are no major changes to the API.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In the process of upgrading G from v4 to v6, the underlying layer of G has been refactored a lot, from a single engine that only provides basic rendering capabilities to a plug-in engine, enriching a lot of ecological capabilities.
Unfortunately, performance issues were not paid close attention to during this process, resulting in a serious regression of performance benchmarks. So far, we have made a lot of efforts to optimize performance, but the results are still not ideal. The root cause is that our current strategy is relatively conservative. If we want to really improve performance, we need to make some adjustments to the current architecture. Considering the developer experience and maintenance costs, this is based on the premise that there are no major changes to the API.
Related performance issues:
Here are some to-do items:
rbushdependencyCompleted optimization (PRs):
Reference performance benchmarks:
Beta Was this translation helpful? Give feedback.
All reactions