| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
| |
This reverts commit 7fce850cffb72a6fbcf763a40164a9b35b7fa833.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Implement AbortController
Signed-off-by: syvb <me@iter.ca>
* Update WPT tests
Signed-off-by: syvb <me@iter.ca>
* Address review comments
* Fix duplicate import generation
* Update WPT test expectations
* Change expectation to FAIL for flaky test
---------
Signed-off-by: syvb <me@iter.ca>
|
| |
|
|
|
|
|
| |
This directory now contains third_party software that is vendored into
the Servo source tree. The idea is that it would eventually hold
webrender and other crates from mozilla-central as well with a standard
patch management approach for each.
|
| | |
|
| | |
|
| | |
|
|
|
When playing around with Cargo’s new timing visualization:
https://internals.rust-lang.org/t/exploring-crate-graph-build-times-with-cargo-build-ztimings/10975/21
… I was surprised to see the `script` crate’s build script take 76 seconds.
I did not expect WebIDL bindings generation to be *that* computationally
intensive.
It turns out almost all of this time is overhead. The build script uses CMake
to generate bindings for each WebIDL file in parallel, but that causes a lot
of work to be repeated 366 times:
* Starting up a Python VM
* Importing (parts of) the Python standard library
* Importing ~16k lines of our Python code
* Recompiling the latter to bytecode, since we used `python -B` to disable
writing `.pyc` file
* Deserializing with `cPickle` and recreating in memory the results
of parsing all WebIDL files
----
This commit remove the use of CMake and cPickle for the `script` crate.
Instead, all WebIDL bindings generation is done sequentially
in a single Python process. This takes 2 to 3 seconds.
|
