-
Notifications
You must be signed in to change notification settings - Fork 212
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
remove install-metering-and-ses from apps and most unit tests #3393
Conversation
The tests that actually need to exercise metering now use `xs-worker` instead of enabling global metering. This speeds those tests up by 4x-6x. refs #3373
All metered vats should now be using xsnap, so we no longer need to meter 'local' vats, and can remove the performance-costly global metering wrapper. refs #3373
All metered vats should now be using xsnap, so we no longer need to meter 'local' vats, and can remove the performance-costly global metering wrapper. refs #3373
I ran my testnet-load-generator recipe to test this (
which makes me think the wallet deploy is using the spawner (which does not make a new dynamic vat? I forget) and the within-vat metering code (the other thing we want to rip out). I suspect that means whatever code is being loaded is subject to the metering transform but not running with meter-transformed globals, so it's even less meter-confined than before. @michaelfig can you imagine this being a problem for the next week? I'm guessing it's ok. The loadgen sequence seemed to run without problems. I haven't yet investigated how performance might have changed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
The spawner does make a new dynamic vat. The problem is apparently that the
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just needs to update packages/solo
to use 'xs-worker'
.
This changes the solo node to use xs-worker (xsnap) vats instead of local ones, which has a secondary effect of silencing a warning from the spawner as it attempts to create a metered vat without the Node.js globals having been wrapped for metering. refs #3393
@michaelfig I'm cool with switching I made the two changes you recommended, but I'm still seeing that warning message on the client:
I'm wondering if something in But, I'll land this once CI passes. |
Maybe:
??? |
The config file needed updating too.
That did the trick, thanks! Will land as soon as CI finishes. |
This changes the solo node to use xs-worker (xsnap) vats instead of local ones, which has a secondary effect of silencing a warning from the spawner as it attempts to create a metered vat without the Node.js globals having been wrapped for metering. refs #3393
At this point, any dynamic vats that need to be metered should be run under
xsnap
, notlocal
, which means we no longer need to use@agoric/install-metering-and-ses
to wrap the globals with metered versions. Those wrappers cause a significant slowdown in all Node.js-side code (like the kernel), even when metering is not enabled, so it's nice to remove them.This changes
spawner
andzoe
tests which need to exercise metering to use anxsnap
worker. All instances ofimport '@agoric/install-metering-and-ses'
have been changed toimport '@agoric/install-ses'
. This reduces the runtime of those tests by 4x-6x (in one case, Zoe'stest-crashingContract.js
, reducing it from 340s to 60s).Most importantly, this changes our two main applications (
cosmic-swingset
and thesolo
node) in the same way. We don't have measurements on the performance changes, but we expect them to be noticeable.refs #3373
Probably doesn't close it yet, there are still some swingset internal tests that exercise that metering code which needs to be changed.