search

trufflesuite / truffle-compile

Compiler helper and artifact manager
22 stars 46 forks source link

Parse imports correctly (built compilers) #65

Closed cgewecke closed 6 years ago

cgewecke commented 6 years ago

Fixes #64.

Uses solcjs to resolve import paths when running a built compiler. Solcjs needs to be matched to the built version, so the first time a built compiler runs there's additional overhead for the remote fetch (~5 sec). That said running with docker is more than twice as fast. Native might be faster. Zeppelin's entire suite (dozens of contracts) compiles in ~11 seconds vs. ~27 seconds (JS) on my box. Import parsing overhead without the fetch seems negligible, ~1 sec.

Also:

cgewecke commented 6 years ago

The whole parseImports mechanism is built around a special JS callback that's documented here. Not sure what we'd do instead because I don't see a comparable parsing option in the command line solc docs. We have quite a bit of pre-processing that doesn't necessarily fit into the way command-line solc is designed? Idk.

gnidan commented 6 years ago

The whole parseImports mechanism is built around a special JS callback that's documented here. Not sure what we'd do instead because I don't see a comparable parsing option in the command line solc docs. We have quite a bit of pre-processing that doesn't necessarily fit into the way command-line solc is designed? Idk.

That's fascinating! Thanks for filling in the gaps in my mental model of this stuff.

Doing a bit of investigating for my own curiosity, this comment seems to suggest we'd be able to avoid using that callback, given a bit of extra trouble.

Trying this out with the native solc, it looks like we could search for import errors ourselves - see gist.

Not saying it's worth the effort, but it might be later.

cgewecke commented 6 years ago

@gnidan Yes agree this definitely seems possible. . .

cgewecke commented 6 years ago

Thought a bit more about this - probably worth profiling and might also require we revise the minimization algo to reduce computational complexity.

My impression while debugging for the PR was that solcjs parses this stuff very quickly ( ~ 1 sec for Zeppelin). parseImports runs for each file (potentially more than once in normal use). If solc is a docker this might be bad because spin-up could be in the 300ms - 900ms range depending on OS. We'd want to do that once, and possibly not at all.

Would be nice if solc exposed the parser as a separate piece of functionality.

gnidan commented 6 years ago

@cgewecke ah, thanks for following up to find that out. Unfortunate that solc doesn't just expose the parser. I'll ask them if I should open an issue for that.