Experimental fork

[douglasduteil]

I'm doing my own experimentation in a fork The goal is to provide an server capable of

• [x] Use HTTP2 / SPYD / HTTP (with or without ssl)
• [x] Tracing dependencies graph for System.js
• [x] Doing some back end transpilation
• [x] In memory pre bundling
• [ ] Re-adding your cold/hot reload

I publish my result on npm so we can test stuff. douglasduteil...jspm-server

[douglasduteil]

douglasduteil...jspm-server experiments results

Here comes the raw results

HTTP 1

• No config
• Record

• HAR

• RAW HAR

HTTP 2

• Config

'use strict'

module.exports = {
  root: __dirname,
  ssl: true
}

• Record

• HAR

• RAW HAR

HTTP 2 and a generated Systemjs#depCache

• Config

'use strict'

module.exports = {
  root: __dirname,
  ssl: true,
  transformer: {
    files: {
      pattern: [
        'src/*.js'
      ]
    }
  },
  system: {
    configFile: './config.js',
    depCache: ['css', 'babel', 'src/main.js']
  }
}

• Record

• HAR

• RAW HAR

HTTP 2 and a generated Systemjs#bundles

• Config

'use strict'

module.exports = {
  root: __dirname,
  ssl: true,
  system: {
    configFile: './config.js',
    depCache: [],
    bundles: [
      'css + src/main - [src/**/*] - [src/**/*.css!]',
    ]
  }
}

• Record

• HAR

• RAW HAR

[douglasduteil]

Following https://github.com/jspm/jspm-cli/issues/872 #4 #29

[guybedford]

This is very enlightening. The lack of a speed up here seems like it may be due to:

• With naive HTTP/2 everything loads in parallel without priority. This means that the smallest file sizes complete transfer first.
• The babel browser.js file which is the largest finishes last.
• Execution then begins, as no process execution is possible until the babel file has executed.
• As a result we then have to parse and execute all scripts after the fetch cycle, while in the HTTP/1 case, execution and script parsing was better interleaved with the fetching process itself.

It seems like there is the potential here for a big performance boost if the server was aware of the dependency tree priorities and optimized the HTTP/2 transport itself to ensure critical resources are transferred first. For example, simply raising the priority of babel here would likely reduce time significantly.

[douglasduteil]

Hi there @guybedford it's been a while now. Sorry... I'm back now.

Did something change on this subject ? I would like to tackle it but I can't find how. You were saying (5 month ago) that

It seems like there is the potential here for a big performance boost if the server was aware of the dependency tree priorities and optimized the HTTP/2 transport itself to ensure critical resources are transferred first.

• Can systemjs-builder#trace functions be use to extract the priority of a dependency (through the depth of this dependency) ?
• Is it systemjs in depcache mode that from the client sends the requests with priorities inside the header ?

Looking forward to work with you again :) Douglas.

[guybedford]

@douglasduteil nice to hear you're interested in some experimenting here. Yes SystemJS builder trace contains everything that is needed to know about the tree to handle prioritisation as it provides the graph. Reading that graph can be seen in for example https://github.com/systemjs/builder/blob/master/lib/compile.js#L148.

SystemJS depcache effectively does equal prioritisation, but because all loads are on the critical path it's mostly ok. Where a prioritised depCache would help is for plugin loads, see https://github.com/systemjs/systemjs/issues/263.

Another big thing for speedup is server-side precompilation of the SystemJS translate hook. I've been working on a test for this in https://github.com/guybedford/karma-systemjs-experiment which you may find interesting as well.