fetchzip: cleanup and improve metrics

[oxij]

This cleans up fetchzip and fetchurl derivations a bit, improving Nixpkgs metrics.

fetchzip seems to change semantics with me removing arguments there, but it does not, since all that pname logic was ignored by underlying fetchurl anyway.

[oxij]

@amjoseph-nixpkgs

.. although the eval performance report shows only ~0.1% improvement on any metric other than cpu time (which is a very noisy metric)...

Yes, this whole thing was a bit disheartening for me. Changes that make huge improvements to local eval produce negative results on OfBorg and vice versa.

[oxij]

Okay, so, apparently OfBorg's gc-heapSize in evaluation result is just very noisy. Applying 9437e4d, which is basically a noop (since the condition is never true), improved everything, except gc-heapSize, which got worse. It is also noisy on my machine, but not that noisy. But I'm not evaluating everything, my evaluations usually take 14GiB of RAM, OfBorg's ~41GiB. So, it makes sense it's about 4x as noisy.

Compare:
https://github.com/NixOS/nixpkgs/runs/15715151966
https://github.com/NixOS/nixpkgs/runs/15717732275

So, this is done, I think.

[oxij]

ping @SuperSandro2000 @hraban who edited pname logic before.

Note how fetchurl already does this part in https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchurl/default.nix#L135 completely ignoring the name in fetchzip when pname and version are set, so there's no need to duplicate that piece of code.

[hraban]

why did you remove this comment? Is it obsolete?

[oxij]

I did not, I moved it down below.

[hraban]

Gotcha. So this is all moved around as an optimization, if I understand your other comments--Is removing these string literal concatenations actually a noticeable improvement? Seems like a pretty basic optimization step for nix to take, I'm surprised this is noticeable :/ what's the speedup?

[oxij]

There's probably no speedup there, but it does take less allocations.

[oxij]

Thanks @amjoseph-nixpkgs!