Re: [PATCH v3 00/34] libify mailinfo and call it directly from am
From: Stefan Beller <hidden>
Date: 2016-06-15 23:06:56
On Tue, Oct 20, 2015 at 2:24 PM, Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:quoted
During the discussion on the recent "git am" regression, I noticed that the command reimplemented in C spawns one "mailsplit" and then spawns "mailinfo" followed by "apply --index" to commit the changes described in each message. As there are platforms where spawning subprocess via run_command() interface is heavy-weight, something that is conceptually very simple like "mailinfo" is better called directly inside the process---something that is lightweight and frequently used is where the overhead of run_command() would be felt most.Although I still haven't seen any offer to help from those who work on the platforms that may benefit from this series the most, I have some numbers on my desktop (Dell T3500 2.66GHz Xeon X5650 with 12GB, running Ubuntu), where the cost of spawning is not as costly as elsewhere, making this series less pressing.
As far as I understand, this only helps for mailing list workflows, which
in my limited view of the world is only found in established infrastructure
projects, who tend to be maintained by people who run some kind of
ab-nomination of unix.
("Are there people in Windows land who heavily use the email workflow?")
Between 'master' and the version with this series (on 'jch'),
applying this 34-patch series itself on top of 'master' using "git
am", best of 5 numbers for running:
time git am mbox >/dev/null
are
(master) (with the series)
real 0m0.648s real 0m0.537s
user 0m0.358s user 0m0.338s
sys 0m0.172s sys 0m0.154s
I haven't re-read the series to catch leaks yet, so in that sense
the series is still not ready to be merged to 'next' (of course,
help with fresh set of eyes is very much appreciated here).I'll take another look after sending out my series.
-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html