Re: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 30, 2015 at 6:58 PM, Gabor Bernat <bernat@xxxxxxxxxxxxxx> wrote:
> I would argue against the every n commit check, or at least making it
> configurable, as in my case the speed is something between 0.01 and
> 1.5 seconds per commit. Checking it every n commit would make it I
> feel quite slow to adapt. But it's debatable.



You must have missed the previous times someone said this, but please
don't top post on this list.



Here are some timings for running the command in question 1000 times
on my computer:
awk 'BEGIN{srand();print srand()}'
 0.32s user 1.20s system 65% cpu 2.332 total

perl -e 'print time'
 0.69s user 1.45s system 73% cpu 2.921 total

date +%s
 0.27s user 0.99s system 78% cpu 1.604 total

and for comparison,
/bin/true
 0.02s user 0.26s system 24% cpu 1.127 total

-- 
Mikael Magnusson
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]