[
https://issues.apache.org/jira/browse/THRIFT-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antony Ducommun updated THRIFT-4570:
------------------------------------
Description:
I propose to add a new compiler generating native typescript code with the
following goals:
* Using promise only
* Reducing the generated code to the minimum
* Fully typed code to avoid misuse of generated code
* Initially geared toward web-browser usage and not nodejs
My understanding is that the usual generator flow is not ideal for javascript
because:
* The advantage of using a streaming parser is lost (cf. initial JSON.parse)
* It's not clear if we gain much by doing a streaming write vs. a
JSON.stringify
* The usual transports available (xhr, websocket) don't mix well with streaming
* The 'speed first' focus is not the first concern I encountered using thrift
in a browser environment. I am usually more concerned by final code bundle size
than the speed at which the messages are serialized.
So I wrote a prototype which produces quite different kind of code compared to
the js generator and the results are interesting. On a set of existing thrift
interfaces, here is the difference in size (fully compressed/minified and
including respective libraries):
* Using standard js generator: 484 Kb
* Using my prototype ts generator: 184 Kb
It's around a 1:2.5 ratio. Some files have up to a 1:5 ratio.
But there is no magic. There is of course a potential performance penalty doing
so, which should be fully evaluated. Also the code needs to be tested and
further optimized. It's still a bit rough at this stage.
I'll open a pull request if there is interest in this direction.
was:
I propose to add a new compiler generating native typescript code with the
following goals:
* Using promise only
* Reducing the generated code to the minimum
* Fully typed code to avoid misuse of generated code
* Initially geared toward web-browser usage and not nodejs
My understanding is that the usual generator flow is not ideal for javascript
because:
* The advantage of using a streaming parser is lost (cf. initial JSON.parse)
* It's not clear if we gain much by doing a streaming write vs. a
JSON.stringify
* The usual transports available (xhr, websocket) don't mix well with streaming
* The 'speed first' focus is not the first concern I encountered using thrift
in a browser environment. I am usually more concerned by final code bundle size
than the speed at which the messages are serialized.
So I wrote a prototype which produce quite different kind of code compared to
the js generator and the results are interesting. On a set of existing thrift
interfaces, here are the difference in size (fully compressed/minified and
including respective libraries):
* Using standard js generator: 484 Kb
* Using my prototype ts generator: 184 Kb
It's around a 1:2.5 ratio. Some files have up to a 1:5 ratio.
But there is no magic. There is of course a potential performance penalty doing
so, which should be fully evaluated. Also the code need to be tested and
further optimized. It's still a bit rough at this stage.
I'll open a pull request if there is interest in this direction.
> New TypeScript generator optimized for size
> -------------------------------------------
>
> Key: THRIFT-4570
> URL: https://issues.apache.org/jira/browse/THRIFT-4570
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General), TypeScript - Library
> Reporter: Antony Ducommun
> Priority: Major
>
> I propose to add a new compiler generating native typescript code with the
> following goals:
> * Using promise only
> * Reducing the generated code to the minimum
> * Fully typed code to avoid misuse of generated code
> * Initially geared toward web-browser usage and not nodejs
> My understanding is that the usual generator flow is not ideal for javascript
> because:
> * The advantage of using a streaming parser is lost (cf. initial JSON.parse)
> * It's not clear if we gain much by doing a streaming write vs. a
> JSON.stringify
> * The usual transports available (xhr, websocket) don't mix well with
> streaming
> * The 'speed first' focus is not the first concern I encountered using
> thrift in a browser environment. I am usually more concerned by final code
> bundle size than the speed at which the messages are serialized.
> So I wrote a prototype which produces quite different kind of code compared
> to the js generator and the results are interesting. On a set of existing
> thrift interfaces, here is the difference in size (fully compressed/minified
> and including respective libraries):
> * Using standard js generator: 484 Kb
> * Using my prototype ts generator: 184 Kb
> It's around a 1:2.5 ratio. Some files have up to a 1:5 ratio.
> But there is no magic. There is of course a potential performance penalty
> doing so, which should be fully evaluated. Also the code needs to be tested
> and further optimized. It's still a bit rough at this stage.
> I'll open a pull request if there is interest in this direction.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
