[
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 a 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 improved. It's still rough at this stage.
Here attached is the output generated for the SmallTest example found in the
thrift tests folder.
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 produces a 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 improved. It's still 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
> Attachments: SmallService.ts, SmallTest.thrift, SmallTest_types.ts,
> thrift.ts
>
>
> 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 a 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 improved. It's still rough at this stage.
> Here attached is the output generated for the SmallTest example found in the
> thrift tests folder.
> I'll open a pull request if there is interest in this direction.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
