Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make a round of performance tuning #538

Open
trusktr opened this issue May 31, 2020 · 7 comments
Open

make a round of performance tuning #538

trusktr opened this issue May 31, 2020 · 7 comments
Assignees

Comments

@trusktr
Copy link
Member

trusktr commented May 31, 2020

There's things we can optimize, like preventing new variable creations, using typeof instead of instanceof, etc.

F.e. here's a test that shows instanceof being slower than typeof:

@trusktr trusktr self-assigned this May 31, 2020
@dalisoft
Copy link
Collaborator

These benchmarks useless unless you have very low-end device, in 2020 thinking about ms isn't good idea, but i may be wrong.
On my notebook with 2-core T2060 with 64Mb GPU memory - yes, it's matters, but gives at least 30FPS on some complex animations
Now even phones even powerful than my old notebook, gives at least 45-50FPS which is enough.

Microbenchmarks isn't good + there not a lot of developers which can spent their time to improve performance

This comment is just my thought, sorry if i'm wrong

@trusktr
Copy link
Member Author

trusktr commented May 31, 2020

Where it really matters is when animating a high number of things. Even if we can only improve performance by, say, 25%, then that's awesome because it means we can animated 2500 objects instead of 2000 (for example). The more performance, the better.

Some people really do care about it, especially if they are making dynamic experiences like first person shooters or similar.

But for the vast majority of use cases (for example, any website with an animation here or there) it probably does not matter.

It's similar to React vs Backbone.js: sure, React is faster, but honestly for the majority of use cases Backbone.js with string-based Handlebars templating is perfectly fine and achieves the same thing (however you will definitely not make a performant first person shooter with it).

@dalisoft
Copy link
Collaborator

dalisoft commented Jun 1, 2020

Yes, you right. I understand you. Thanks for reply.
I really cared about performance always until got job, i learned on job on company: don’t waste time on not important things, so i just said my thought

@trusktr
Copy link
Member Author

trusktr commented Jun 3, 2020

i learned on job on company: don’t waste time on not important things, so i just said my thought

Hehe, true! Gotta weigh the values. (I'm planning to make a web based first person shooter later, so besides this I'd also like to compile Tween.js to WebAssembly. More on that later!)

@dalisoft
Copy link
Collaborator

dalisoft commented Jun 3, 2020

Would be great to see tweenjs in WebAssembly :)
Maybe AssemlyScript good choice?

@trusktr
Copy link
Member Author

trusktr commented Jun 3, 2020

You read my mind! I just merged #544, which converts to TypeScript, and so next steps are to compile the TS with AS.

@trusktr
Copy link
Member Author

trusktr commented Jun 3, 2020

From @mikebolt in #340,

Objects and arrays have a larger footprint than basic types, even when they are empty. For this reason, we could have a 10-20% memory footprint reduction by removing the initialization of _chainedTweens and _valuesStartRepeat. Some refactoring would be required. _chainedTweens could initially be null, then set to an array when 'chain' is called.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants