DUB - call to arms

[Seb]

On Saturday, 27 April 2019 at 01:13:33 UTC, H. S. Teoh wrote:
> In the meantime, it would seem that we need to look into why 
> the "searching for versions" phase takes so long.  Is it just a 
> network-dependent thing (my network has bogonously slow DNS 
> resolution, no thanks to my ISP), or is it something that can 
> be fixed in dub itself?

Thanks a lot for your interest in dub and investigating this!

First off you should never delete your dub.selections.json as it 
locks your project dependencies (it won't be used if your project 
is used as a library).

Anyhow, that being said there are still a ton of things that can 
be done:

- The new single API request feature doesn't work for all 100% 
with optional dependencies (see the respective GitHub PR that 
introduced it for details)
- Dependencies could be checked in parallel
- The registry itself could be optimized more for caching (maybe 
even with a CDN proxy)
...

There are more experimental things we could try like e.g. a fully 
local JSON index that is only updated when needed and supports 
partial updates (think apt), but I believe the bigger gains in 
user-experience will be:

- initial fetch (important for fast CI turnaround times. First 
point of attack: parallelizing the fetching process)
- build times with existing dependencies (important as the 
default case. First points of attack: build independent 
dependencies in parallel, warn if ld.gold isn't the default on 
Linux, ...)