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

Transforming libraries takes a long time #212

Closed
ppcano opened this Issue May 11, 2017 · 12 comments

Comments

Projects
None yet
5 participants
@ppcano
Member

ppcano commented May 11, 2017

Transforming a library takes a long time; making the development flow when using libraries to become unproductive.

Running k6 in verbose mode shows the following result:

import moment from "./vendor/moment.js";
DEBU[0000] Resolved...                name="/Users/ppcano/dev/li/k6-tests/vendor/moment.js"
DEBU[0229] Babel: Transformed       t=3m48.669249149s
import faker from "./vendor/faker.js";
DEBU[0001] Resolved...                      name="/Users/ppcano/dev/li/k6-tests/vendor/faker.js"
DEBU[0114] Babel: Transformed        t=1m53.851882106s
import moment from "s3.amazonaws.com/k6samples/moment.js";
DEBU[0002] Fetched!                          len=128945 t=1.22518284s url="https://s3.amazonaws.com/k6samples/moment.js?_k6=1"
DEBU[0217] Babel: Transformed         t=3m35.005278253s
@liclac

This comment has been minimized.

Show comment
Hide comment
@liclac

liclac May 11, 2017

Collaborator

Yeah... I wanted to give another compiler a shot, but I think we may be hitting the limit of what goja can do here. Maybe we could cache compiled scripts somehow...?

Collaborator

liclac commented May 11, 2017

Yeah... I wanted to give another compiler a shot, but I think we may be hitting the limit of what goja can do here. Maybe we could cache compiled scripts somehow...?

@micsjo

This comment has been minimized.

Show comment
Hide comment
@micsjo

micsjo May 11, 2017

Collaborator

Definitively cache compiled scripts. 3 minutes is already there borderline. Add a couple of them and you can quickly get 15 minutes of startup time just waiting for your 30 second test to run...

Collaborator

micsjo commented May 11, 2017

Definitively cache compiled scripts. 3 minutes is already there borderline. Add a couple of them and you can quickly get 15 minutes of startup time just waiting for your 30 second test to run...

@robingustafsson robingustafsson added this to the July 2017 milestone Jun 16, 2017

@ppcano

This comment has been minimized.

Show comment
Hide comment
@ppcano

ppcano Sep 11, 2017

Member

@liclac Random thoughts on this issue.

I find compiled modules to work differently than other ES6 modules. A compiled module is usually a large Javascript library with a lot of functionality, and ES6 modules are often much smaller modules related to your load testing domain.

Based on the output, it looks the Babel compilation takes a lot of time when including a large library.

I have only a basic idea about goja and babel, but I wonder if k6 could avoid the babel transformation for "compiled modules" and try to load and import them differently.

Member

ppcano commented Sep 11, 2017

@liclac Random thoughts on this issue.

I find compiled modules to work differently than other ES6 modules. A compiled module is usually a large Javascript library with a lot of functionality, and ES6 modules are often much smaller modules related to your load testing domain.

Based on the output, it looks the Babel compilation takes a lot of time when including a large library.

I have only a basic idea about goja and babel, but I wonder if k6 could avoid the babel transformation for "compiled modules" and try to load and import them differently.

@ppcano

This comment has been minimized.

Show comment
Hide comment
@ppcano

ppcano Sep 12, 2017

Member

After a conversation with @liclac, we came to the conclusion that we could support a different API for ES5 modules.

// ES6 module
import utils from './lib/utils.js' 

// ES5 module
const moment = require('./vendor/moment.js')

require will skip the Babel transformation and it can be used to import ES5 modules like bundled Javascript libraries.

Member

ppcano commented Sep 12, 2017

After a conversation with @liclac, we came to the conclusion that we could support a different API for ES5 modules.

// ES6 module
import utils from './lib/utils.js' 

// ES5 module
const moment = require('./vendor/moment.js')

require will skip the Babel transformation and it can be used to import ES5 modules like bundled Javascript libraries.

@liclac

This comment has been minimized.

Show comment
Hide comment
@liclac

liclac Sep 12, 2017

Collaborator

That's not a conclusion as much as it is one possible way to solve it. I don't like it, because it means you need to know if the file you're importing is written in ES5 or ES6.

Collaborator

liclac commented Sep 12, 2017

That's not a conclusion as much as it is one possible way to solve it. I don't like it, because it means you need to know if the file you're importing is written in ES5 or ES6.

@ppcano

This comment has been minimized.

Show comment
Hide comment
@ppcano

ppcano Sep 12, 2017

Member

@liclac

With proper documentation, I don't find having two syntaxes for the different type of modules to be a big issue. This may not be the ideal solution, but it solves this problem at this moment. Later when we found a better way, we can deprecate the ES5 require API and migrate to imports.

Member

ppcano commented Sep 12, 2017

@liclac

With proper documentation, I don't find having two syntaxes for the different type of modules to be a big issue. This may not be the ideal solution, but it solves this problem at this moment. Later when we found a better way, we can deprecate the ES5 require API and migrate to imports.

@liclac

This comment has been minimized.

Show comment
Hide comment
@liclac

liclac Sep 12, 2017

Collaborator

Here's a wild idea: what if we tried parsing the file as ES5, then if there are syntax errors, we run Babel on it and try again.

Collaborator

liclac commented Sep 12, 2017

Here's a wild idea: what if we tried parsing the file as ES5, then if there are syntax errors, we run Babel on it and try again.

@liclac liclac closed this in d51c3ea Sep 12, 2017

@liclac

This comment has been minimized.

Show comment
Hide comment
@liclac

liclac Sep 12, 2017

Collaborator

And... it works! Anything that isn't valid ES5 is now run through Babel and retried. Negligible slowdown for ES6 sources, near-instant loading of arbitrarily large ES5 modules.

Collaborator

liclac commented Sep 12, 2017

And... it works! Anything that isn't valid ES5 is now run through Babel and retried. Negligible slowdown for ES6 sources, near-instant loading of arbitrarily large ES5 modules.

@ppcano

This comment has been minimized.

Show comment
Hide comment
@ppcano

ppcano Sep 12, 2017

Member

@liclac 👏 🥇

Looking forward testing it

Member

ppcano commented Sep 12, 2017

@liclac 👏 🥇

Looking forward testing it

@ppcano

This comment has been minimized.

Show comment
Hide comment
@ppcano

ppcano Sep 18, 2017

Member

@liclac I tested it, and this works perfectly.

Please, could you build a new release including this fix?

After the new release, I will upgrade the Modules doc and promote it again aiming to find new feature testers.

Member

ppcano commented Sep 18, 2017

@liclac I tested it, and this works perfectly.

Please, could you build a new release including this fix?

After the new release, I will upgrade the Modules doc and promote it again aiming to find new feature testers.

@aidylewis

This comment has been minimized.

Show comment
Hide comment
@aidylewis

aidylewis Sep 22, 2017

Collaborator

So, am I right to say k6 supports both ES5 and ES6, but ES5 will compile much faster as it wont need to go through the Babel transpiler and now is a second option?

Collaborator

aidylewis commented Sep 22, 2017

So, am I right to say k6 supports both ES5 and ES6, but ES5 will compile much faster as it wont need to go through the Babel transpiler and now is a second option?

@liclac

This comment has been minimized.

Show comment
Hide comment
@liclac

liclac Sep 22, 2017

Collaborator

No, this is purely a performance increase when loading third-party libraries. ES6 is compiled down to ES5 under the hood, but we don't support writing scripts in ES5 directly and do not guarantee API stability for anything but ES6.

Collaborator

liclac commented Sep 22, 2017

No, this is purely a performance increase when loading third-party libraries. ES6 is compiled down to ES5 under the hood, but we don't support writing scripts in ES5 directly and do not guarantee API stability for anything but ES6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment