git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3/2] Avoid unnecessary strlen() calls

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Mar 20, 2007, 04:31 UTC
Message-ID
<Pine.LNX.4.64.0703192116020.6730@woody.linux-foundation.org>
In-Reply-To
<7v3b40d2os.fsf@assigned-by-dhcp.cox.net>
On Mon, 19 Mar 2007, Junio C Hamano wrote:
> 
> With this stupidity-removal patch, it gets down to 7.80user from
> 8.72user (comparable number of minor faults) for blaming
> block/ll_rw_blk.c (without tglx grafts)
Yeah, this one works for me too. Even more than for you. For me, 
	git blame --incremental -C HEAD block/ll_rw_blk.c

takes 6.71s (best of ten) normally, and 4.85 (best of ten again) with your patch and Nico's one-liner. In fact, that's a much bigger improvement than I would have expected from the profile, but it may be that you just cut the data cache footprint down a lot, and thus made other things more efficient.

(I just double-checked. Nico's one-liner does help, but not nearly as radically as it did for Nico. The "best of ten" with *just* Nico's one-liner is 6.22 for me - better than before, but the combination of Nico's patch and yours is much more dramatic).

Btw, Dscho's slightly more invasive patch seems to *just* edge out Nico's one-liner for me, with best-of-ten being 6.17s.

The winner is your patch *with* Dscho's slightly more invasive one: 4.69s.

But the difference between the numbers of Dscho's bigger patch and Nico's one-liner really are totally in the noise. Dscho *just* wins the best-of-ten both with and without your patch, but in both cases it's *way* in the noise. For example, while 4.69s was the best for your+Dscho in my testing, the full series was

	0:05.69
	0:04.69
	0:04.82
	0:04.97
	0:04.85
	0:05.88
	0:04.77
	0:04.69
	0:05.12
	0:04.98

so the variability was big enough that I wouldn't say that 0.1s is really all that meaningful even for "best of ten". I didn't try to make the machine totally quiescent, I've got xmms playing in the background etc..

But these kinds of things will definitely vary from machine to machine. It's all good, though.

			Linus
Previous: Junio C HamanoNext: Shawn O. Pearce
Message 64 of 79 in “cleaner/better zlib sources?”
  1. Linus TorvaldsMar 16, 2007
  2. Shawn O. PearceMar 16, 2007
  3. Jeff GarzikMar 16, 2007
  4. Matt MackallMar 16, 2007
  5. Linus TorvaldsMar 16, 2007
  6. Linus TorvaldsMar 16, 2007
  7. Davide LibenziMar 16, 2007
  8. Linus TorvaldsMar 16, 2007
  9. Davide LibenziMar 16, 2007
  10. Linus TorvaldsMar 16, 2007
  11. Davide LibenziMar 16, 2007
  12. Linus TorvaldsMar 16, 2007
  13. Davide LibenziMar 16, 2007
  14. Linus TorvaldsMar 17, 2007
  15. Linus TorvaldsMar 17, 2007
  16. Nicolas PitreMar 17, 2007
  17. Shawn O. PearceMar 17, 2007
  18. Linus TorvaldsMar 17, 2007
  19. Linus TorvaldsMar 17, 2007
  20. 1/2 Make trivial wrapper functions around delta base generation and freeingLinus Torvalds, Mar 17, 2007
  21. 2/2 Implement a simple delta_base cacheLinus Torvalds, Mar 17, 2007
  22. Linus TorvaldsMar 17, 2007
  23. Junio C HamanoMar 17, 2007
  24. Linus TorvaldsMar 17, 2007
  25. Linus TorvaldsMar 17, 2007
  26. Nicolas PitreMar 18, 2007
  27. Junio C HamanoMar 18, 2007
  28. Junio C HamanoMar 17, 2007
  29. Linus TorvaldsMar 17, 2007
  30. Jon SmirlMar 17, 2007
  31. Morten WelinderMar 18, 2007
  32. Linus TorvaldsMar 18, 2007
  33. Nicolas PitreMar 18, 2007
  34. Linus TorvaldsMar 18, 2007
  35. Nicolas PitreMar 18, 2007
  36. Linus TorvaldsMar 18, 2007
  37. Nicolas PitreMar 18, 2007
  38. Linus TorvaldsMar 18, 2007
  39. Julian PhillipsMar 18, 2007
  40. Linus TorvaldsMar 18, 2007
  41. Robin RosenbergMar 18, 2007
  42. Linus TorvaldsMar 18, 2007
  43. Robin RosenbergMar 18, 2007
  44. Shawn O. PearceMar 18, 2007
  45. David BrodskyMar 19, 2007
  46. Robin RosenbergMar 20, 2007
  47. David BrodskyMar 20, 2007
  48. Linus TorvaldsMar 21, 2007
  49. Nicolas PitreMar 21, 2007
  50. 3/2 Avoid unnecessary strlen() callsLinus Torvalds, Mar 18, 2007
  51. Junio C HamanoMar 18, 2007
  52. Linus TorvaldsMar 18, 2007
  53. Linus TorvaldsMar 18, 2007
  54. Shawn O. PearceMar 18, 2007
  55. Linus TorvaldsMar 18, 2007
  56. Johannes SchindelinMar 20, 2007
  57. Shawn O. PearceMar 20, 2007
  58. Shawn O. PearceMar 20, 2007
  59. Linus TorvaldsMar 20, 2007
  60. Shawn O. PearceMar 20, 2007
  61. Linus TorvaldsMar 20, 2007
  62. Junio C HamanoMar 20, 2007
  63. Junio C HamanoMar 20, 2007
  64. Linus TorvaldsMar 20, 2007
  65. Shawn O. PearceMar 20, 2007
  66. Linus TorvaldsMar 20, 2007
  67. Linus TorvaldsMar 18, 2007
  68. Avi KivityMar 18, 2007
  69. Linus TorvaldsMar 17, 2007
  70. Jeff GarzikMar 16, 2007
  71. Matt MackallMar 16, 2007
  72. Linus TorvaldsMar 16, 2007
  73. Nicolas PitreMar 16, 2007
  74. Shawn O. PearceMar 16, 2007
  75. Nicolas PitreMar 16, 2007
  76. Linus TorvaldsMar 16, 2007
  77. Nicolas PitreMar 16, 2007
  78. Davide LibenziMar 16, 2007
  79. Davide LibenziMar 16, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.