Clean up the bytecode comparison scripts

[cameel]

Extracted from #4698 (comment). Related to #9931.

@ekpyron

That being said, I did only do the minimal amount of work to get it running again in #10039 - it would be nice to clean up the mechanism a bit. I.e. scripts/bytecodecompare/storebytecode.sh for the emscripten case is rather horrible - we could actually just run the solcjs wrapper script from the solc-js repo as solc to run it with the scripts/bytecodecompare/prepare_report.py script instead of using this horrible on-the-fly temporary javascript file produced by the script, etc...

[cameel]

Another small improvement to do here would be replacing the manual stripping of SMTChecker pragmas in https://github.com/ethereum/solidity/blob/v0.7.4/scripts/bytecodecompare/prepare_report.py#L17 with the JSON equivalent of the recently introduced (#10036) --model-checker-engine none option.

[cameel]

@ekpyron As I said on the call today, removing the JS snippet from storebytecode.sh and running solcjs from prepare_report.py works but is sloooooooooooooooooooooooooow. It starts a new node.js process and loads the compiler from scratch for every compiler call.

For this reason I don't think we can get rid of it completely, but we could trim it a bit and convert it into a wrapper for batch compilation that accepts a series of JSON files as input and produces corresponding output JSON files - without making assumptions about what's in it. Writing the input/output out to disk would be less optimal but I think the difference in performance would be negligible and it would allow us to keep the input/output processing logic unified in prepare_report.py.

[ekpyron]

It's fine not to replace the snippet - but did you check exactly what happens? My guess would be that it's not the loading of the compiler, but the issue of node not exiting properly, a.k.a #9297... If you're up for it you can check that and add process.exit(0); unconditionally to the very end of https://github.com/ethereum/solc-js/blob/master/solcjs ...

[ekpyron]

That being said it is a lot of contracts, so keeping one instance of node and the compiler for all of them may still help independently of #9297, so as I said: fine not to change anything about it.

[cameel]

I think that's not it. I'm running node.js 14 and the delay I saw was more like ~1 second per call than the 7 seconds we're seeing there (I made it print a pair of messages around every compiler call). It still adds up over several thousand compilations.

Actually I do see a ~5 second delay when I run this snippet manually on the command line:

node -e "console.log('begin'); console.log(require('./index.js').version()); console.log('end')"

and this is weird because I'm not on node.js 10 and delay is much smaller when I run solcjs from prepare_report.py. But even then I can see that loading the compiler is not instant. It takes it that ~1 second to print the version so it would be that slow even if we fixed #9297.

so as I said: fine not to change anything about it.

I'd prefer to change it actually. The main reason I'm touching it now is that I need to add a bit more functionality there to be able to run solc via CLI too and parse the output. I could limit my changes only to prepare_bytecode.py (because AFAIK there's no way to run CLI via solc-js anyway; solcjs just simulates it using standard JSON internally) but it's bugging me that we have a part of this logic duplicated in the JS snippet. That will lead to them getting out of sync down the line.