Cache vsn information during the run to avoid extra unnecessary shell calls

[yrashk]

My experiments showed that I can save a lot of time compiling a complex project by caching vsn information.

Here's the original up-to-date rebar timing (no compilation incurred, everything is up-to-date):

11.26s user 1.77s system 106% cpu 12.277 total

And here's after this patch:

6.47s user 0.78s system 113% cpu 6.364 total

Please consider merging it in.

[jlouis]

I don't know enough about rebar, but given the compile speedup, I'd like to see this get in.

[DeadZen]

+1

[Licenser]

+42

[ghost]

For reference, what's the timed rebar invocation? Just rebar compile?

It may be a far-fetched use case, but won't the patch break
rebar compile update-deps compile
?

[yrashk]

Yes, just rebar compile. The patch is likely to break that edge case, yes, unless we reinitialize the cache table in update-deps... or just before every command.

[yrashk]

WDYT? Should we wipe out the table before each command?

[ghost]

Not sure this is the right approach. Have to think.
Do you have many deps or deps with deep history where git describe is not instant?
How many sub directories have to be processed by rebar?
rebar_deps:preprocess/2 calling update_deps_code_path/1 may be the biggest culprit.

[yrashk]

I have quite a lot of deps, and as you can see, caching git describe saves me a lot of time even on a dry run

[ghost]

Let's revise the patch to wipe out the table before each command and get it merged.

[yrashk]

@Tuncer updated

[ghost]

Thanks, merged.