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

[Question] Have you considered representing the opcode output as an ES6 Typed Array? #147

Closed
AKST opened this issue Apr 23, 2016 · 4 comments

Comments

@AKST
Copy link

AKST commented Apr 23, 2016

Apologises if this is the wrong place to ask this, but I watched the awesome talk by Godfrey & Yehuda on the upcoming changes to glimmer, and I couldn't help but notice you guys were representing your op code as a series of arrays and strings. I had a further look at the source and (I think) that is the case. Have you considered outputting the opcode in the form of a typed array?

Most of the performance boosts would come from the fact Typed arrays have a contingent memory layout, which could likely lower memory usage, provide an additional execution boosts, and could decrease the overall network footprint. The main drawback I can think of is the lack of IE 9/8, or Opera mini support.

Thoughts?

@AKST AKST changed the title [Question] Represent Opcode as byte code in typed arrays? [Question] Have you considered representing the opcode output as an ES6 Typed Array? Apr 23, 2016
@Turbo87
Copy link
Member

Turbo87 commented Jan 7, 2017

@AKST i think the issue with your suggestion is that the wire format is JSON and if I understand correctly typed arrays are a JS feature, but not supported by JSON

@AKST
Copy link
Author

AKST commented Jan 12, 2017

Not sure why I specified typed arrays originally, but you are correct. However looking back on the initial issue I made I probably meant to suggestion the templates could be compiled down to a binary format verses a JSON format.

Like it would be significantly more complex to implement, but the performance increase would probably negate that. Idk, I might close this ticket though because this type of implementation probably does align with the future of ember.

@AKST AKST closed this as completed Jan 12, 2017
@GavinJoyce
Copy link
Contributor

GavinJoyce commented Jan 12, 2017

@AKST
Copy link
Author

AKST commented Jan 12, 2017

This is probably what i had in mind when I posted the issue, cheers!

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

3 participants