Comments (4)
Posting my initial thoughts here. Keep in mind that some of this is speculation and isn't a reason to at least give it a shot:
Precompilation/minification
I don't think minification improves performance for anything but transfer over the wire. If it's loading from localhost
, this is very little time (as in microseconds to transfer a few hundred KB). Precompilation would definitely be great, though. If the Opal compiler doesn't have to process it and only needs to compile the app, that would help a lot unless the Opal::Builder
instance is reused between spec runs, in which case the compiled RSpec will be cached.
Closure compilation?
AFAIK, most JS VMs will not compile a function at all until it is executed. I'd need to run more benchmarks to be sure about it, though.
Other profiling
I can see what I can do about this. I've got a couple ideas, but just to clarify before I spend too much time on it, opal-rspec
does use the actual RSpec gem code, right? We may be limited in performance by RSpec internals if so.
When specific examples are focused on, see if they can be filtered out BEFORE opal compilation
This would probably be pretty cool, but I wonder if the effort would be worth it. We could check the benefit by precompiling a spec run with and without unfocused specs (that is, literally remove unfocused specs from the spec code) and timing the compilation time. Then run each of those and check the runtimes.
My hypothesis is that they would differ only slightly and that the RSpec load time would dwarf it no matter what we do.
reduce the exception throwing just to get stack traces
This might have a pretty big performance impact for failing specs. Exceptions are probably the worst-performing thing you can do in a JS VM. Generating an exception, throwing it, and catching it all cause deoptimizations โย which is bad enough on its own, but the process of unwinding the stack and generating that stack trace is also slow inside the VM itself.
JRuby (at least pre-9k) suffers from this same problem and for almost the same reason. MRI has internal optimizations for generating stack traces (so you can call caller
from anywhere, not just in exceptions), but most other VMs for any language don't.
from opal-rspec.
@jgaskins - Thanks for the info. I'll close this now the the main next step will be to get rid of the metadata exception throws to get trace info.
from opal-rspec.
@jgaskins - Just so you know, the exception throwing I mentioned above used to happen for every example, not just failing ones. It was being used to give RSpec metadata about where each example is (RSpec normally uses #caller
on MRI). On master now, this has been removed and there is no location data for examples until they fail, at which point there is a stack trace.
from opal-rspec.
@jgaskins - https://github.com/karma-runner/karma-closure is doing number 4. In my case, I'd have to do it with a webpack/opal loader because I decided getting into the guts of Karma with https://github.com/wied03/karma-opal-rspec/ was a losing proposition.
from opal-rspec.
Related Issues (20)
- issues with opal 0.10.0 HOT 4
- Results Reporting Sync/Async HOT 1
- filter_run_excluding not working? HOT 1
- how to require gem or a source file ? HOT 5
- stub_const doesn't work quite the same in opal 0.9 HOT 9
- Opal-Master Compatibility
- Sprockets HOT 1
- Support random order HOT 2
- Opal::RSpec::RakeTask HOT 4
- `expect_any_instance_of` is not working when using opal master HOT 5
- Trying to run phantomjs or in-browser tests throws Sprockets::FileNotFound HOT 3
- Get ` cannot load such file -- rake` when run test in browser. HOT 2
- Could not found jquery when use node as task runner. HOT 1
- spec not worked with opal 0.11. (chrome headless) HOT 11
- Unable to require 'nodejs' in spec HOT 2
- uninitialized constant OPAL_PLATFORM HOT 8
- Headless Chrome support HOT 3
- Can you release a new version? HOT 3
- opal-rspec --init leads to erro cannot load such file -- opal-sprockets (LoadError) HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opal-rspec.