You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I run the command-line amphtml-validator program on a Compute Engine e2-micro instance. I just started receiving the error added by #34213 for #36110:
The native JavaScript AMPHTML Validator (validator.js) has been turned down. If you are seeing this error, update your tooling to instead load the API compatible WebAssembly AMPHTML Validator (validator_wasm.js) instead.
% time /home/node/bin/amphtml-validator --format=json - <minimum_valid_amp.html
{"-":{"status":"PASS","errors":[]}}
/home/node/bin/amphtml-validator --format=json - < minimum_valid_amp.html 7.02s user 0.34s system 140% cpu 5.251 total
% time /home/node/bin/amphtml-validator --format=json - <minimum_valid_amp.html
{"-":{"status":"PASS","errors":[]}}
/home/node/bin/amphtml-validator --format=json - < minimum_valid_amp.html 7.54s user 0.31s system 139% cpu 5.612 total
I'm not sure how to run the old non-WebAssembly version for comparison (since it returns errors now), but I believe it was typically able to validate much more complicated pages in around a second on the same instance.
Now that amphtml-validator is wrapping a validator that's apparently written in C++, would a natively-compiled version of amphtml-validator be a possibility for the future, or are there too many additional dependencies on Node.js?
Alternately, are there any suggestions for getting the new validator to run faster on slow VM instances? I'd prefer to stick with the Debian-maintained version of Node.js, but I could switch to e.g. Node.js 16 if there's reason to believe that Wasm performance will be significantly better there.
Reproduction Steps
Create an e2-micro GCE instance using Debian 11.2.
Install the nodejs 12.22.5~dfsg-2~11u1 and npm 7.5.2+ds-2 Debian packages.
Run npm install amphtml-validator.
Pass a trivial file to the amphtml-validator program via stdin.
Relevant Logs
No response
Browser(s) Affected
No response
OS(s) Affected
No response
Device(s) Affected
No response
AMP Version Affected
No response
The text was updated successfully, but these errors were encountered:
Thanks for the reply! I wasn't aware that multiple files could be passed to amphtml-validator, but I can confirm that on the GCE instance I was using before, it takes essentially the same amount of wall time (~5.7s) to validate 27 "real" files in a single run as it does to validate minimum_valid_amp.html. I'll find a way to process everything in a single call.
Description
I run the command-line
amphtml-validator
program on a Compute Enginee2-micro
instance. I just started receiving the error added by #34213 for #36110:After upgrading to
1.0.35
, the validator is much slower, to the point where it's no longer suitable for my workflow. Validating https://raw.githubusercontent.com/ampproject/amphtml/master/validator/testdata/feature_tests/minimum_valid_amp.html takes more than 5 seconds of wall time:I'm not sure how to run the old non-WebAssembly version for comparison (since it returns errors now), but I believe it was typically able to validate much more complicated pages in around a second on the same instance.
Now that
amphtml-validator
is wrapping a validator that's apparently written in C++, would a natively-compiled version ofamphtml-validator
be a possibility for the future, or are there too many additional dependencies on Node.js?Alternately, are there any suggestions for getting the new validator to run faster on slow VM instances? I'd prefer to stick with the Debian-maintained version of Node.js, but I could switch to e.g. Node.js 16 if there's reason to believe that Wasm performance will be significantly better there.
Reproduction Steps
e2-micro
GCE instance using Debian 11.2.nodejs 12.22.5~dfsg-2~11u1
andnpm 7.5.2+ds-2
Debian packages.npm install amphtml-validator
.amphtml-validator
program via stdin.Relevant Logs
No response
Browser(s) Affected
No response
OS(s) Affected
No response
Device(s) Affected
No response
AMP Version Affected
No response
The text was updated successfully, but these errors were encountered: