Slice the gocache and go mod layers so that caching/restoring speed is improved

[djoyahoy]

Currently the entire gocache is stored in one layer. The same is true for the go modules. We may be able to improve layer caching/restoring performance if we slice the gocache and go mod layers into many separate layers. I don't have any actual evidence that this will improve performance, but it makes sense on a conceptual level as very few things will change in the modules and cache between builds. Finally, the layout of the gocache and the go modules directories are already setup for convenient slicing because they contain well distributed sub-directories.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/171135992

The labels on this github issue will be updated when the story is started.

[djoyahoy]

Just to add to this, it's possible this will just introduce un-needed complexity and the real reason the builds are somewhat slow is that we don't really calculate any metadata for the go cache layer. So that is something else to consider.

[ForestEckhardt]

@djoyahoy This is an interesting idea, but I think we would either need to put together a POC or have one provided for benchmarking before we decided to tackle this problem. If you would be willing to put together a POC for this I would love to benchmark it and see if this does improve rebuild times. Otherwise, I am sure we will get around to benchmarking this idea in the future.

[ryanmoran]

This buildpack has been entirely rewritten since this issue was filed. I am going to close this issue. Please feel free to reopen this issue with new reproduction criteria. We'd be happy to take a look again.