From: Walter Bright <firstname.lastname@example.org> To: email@example.com Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library. Date: Fri, 07 Sep 2007 12:23:16 -0700 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <46E11CE1.email@example.com> Andreas Ericsson wrote: > Walter Bright wrote: >> 1) You wind up having to implement the complex, dirty details of >> things yourself. The consequences of this are: >> >> a) you pick a simpler algorithm (which is likely less efficient - I >> run across bubble sorts all the time in code) >> >> b) once you implement, tune, and squeeze all the bugs out of those >> complex, dirty details, you're reluctant to change it. You're >> reluctant to try a different algorithm to see if it's faster. I've >> seen this effect a lot in my own code. (I translated a large body of >> my own C++ code that I'd spent months tuning to D, and quickly managed >> to get significantly more speed out of it, because it was much simpler >> to try out different algorithms/data structures.) >> > > I haven't seen this in the development of git, although to be fair, you > didn't mention the number of developers that were simultaneously working > on your project. On my project, one. But I've seen this problem repeatedly in other projects that had multiple developers. For example, I used to use version 1 of an assembler. It was itself written entirely in assembler. It ran *incredibly* slowly on large asm files. But it was written in assembler, which is very fast, so how could that be? Turns out, the symbol table used internally was a linear one. A linear symbol table is easy to implement, but doesn't scale well at all. A linear symbol table was implemented because it was just harder to do more advanced symbol table algorithms in assembler. In this case, a higher level language re-implementation made the assembler much faster, even though that implementation was SLOWER in every detail. It was faster overall, because it was easier to develop faster algorithms. > If it was you alone, I can imagine you were reluctant to > change it just to see if something is faster. My point was that when I reimplemented it in D, the cost of changing the algorithms got much lower, so I was much more tempted to muck around trying out different ones. The result was I found faster ones. > Opensource projects with many contributors (git, linux) work differently, > since one or a few among the plethora of authors will almost always be > a true expert at the problem being solved. That is a nice advantage. I don't think many projects can rely on having the best in the business working on them, though <g>. > The point is that, given enough developers, *someone* is bound to > find an algorithm that works so well that it's no longer worth > investing time to even discuss if anything else would work better, > either because it moves the performance bottleneck to somewhere else > (where further speedups would no longer produce humanly measurable > improvements), or because the action seems instantanous to the user > (further improvements simply aren't worth it, because no valuable > resource will be saved from it). Sure, but I suggest that few projects reach this maxima. Case in point: ld, the gnu linker. It's terribly slow. To see how slow it is, compare it to optlink (the 15 years old one that comes with D for Windows). So I don't believe there is anything inherent about linking that should make ld so slow. There's some huge leverage possible in speeding up ld (spreading out that saved time among all the gnu developers). So while git may have reached a maxima in performance, I don't think this principle is applicable in general, even for very widely used open source projects that would profit greatly from improved performance. ------ Walter Bright http://www.digitalmars.com C, C++, D programming language compilers http://www.astoriaseminar.com Extraordinary C++
next prev parent reply other threads:[~2007-09-07 19:23 UTC|newest] Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-09-04 20:50 Lukas Sandström 2007-09-04 21:38 ` Alex Riesen 2007-09-04 23:01 ` Pierre Habouzit 2007-09-05 14:54 ` Kristian Høgsberg 2007-09-05 17:29 ` Matthieu Moy 2007-09-06 2:30 ` Miles Bader 2007-09-06 4:48 ` Dmitry Kakurin 2007-09-06 4:59 ` Shawn O. Pearce 2007-09-06 9:12 ` Andreas Ericsson 2007-09-06 9:35 ` Junio C Hamano 2007-09-06 10:21 ` Andreas Ericsson 2007-09-06 9:52 ` David Kastrup 2007-09-06 5:03 ` Miles Bader 2007-09-06 12:08 ` Johannes Schindelin 2007-09-06 17:50 ` Linus Torvalds 2007-09-07 0:21 ` Dmitry Kakurin 2007-09-07 0:38 ` Linus Torvalds 2007-09-07 1:08 ` Dmitry Kakurin 2007-09-07 1:27 ` Linus Torvalds 2007-09-07 3:09 ` Dmitry Kakurin 2007-09-07 5:48 ` David Symonds 2007-09-07 6:15 ` Theodore Tso 2007-09-20 14:06 ` Steven Burns 2007-09-20 14:56 ` Andreas Ericsson 2007-09-07 6:31 ` Andreas Ericsson 2007-09-07 22:17 ` Dmitry Kakurin 2007-09-07 22:28 ` David Kastrup 2007-09-08 0:37 ` Dmitry Kakurin 2007-09-08 6:25 ` David Kastrup 2007-09-09 0:29 ` Andreas Ericsson 2007-09-07 6:52 ` David Kastrup 2007-09-07 10:28 ` Johannes Schindelin 2007-09-07 10:26 ` Johannes Schindelin 2007-09-07 6:50 ` David Kastrup 2007-09-07 1:12 ` Linus Torvalds 2007-09-07 1:40 ` alan 2007-09-07 5:09 ` Walter Bright 2007-09-07 7:40 ` David Kastrup 2007-09-07 8:15 ` Walter Bright 2007-09-07 8:26 ` David Kastrup 2007-09-07 9:14 ` Walter Bright 2007-09-07 9:31 ` David Kastrup 2007-09-07 20:22 ` Walter Bright 2007-09-07 20:27 ` David Kastrup 2007-09-07 23:16 ` Walter Bright 2007-09-08 23:50 ` Andreas Ericsson 2007-09-09 0:37 ` Pierre Habouzit 2007-09-09 1:36 ` Andreas Ericsson 2007-09-07 11:36 ` Wincent Colaiuta 2007-09-07 9:41 ` Pierre Habouzit 2007-09-07 19:03 ` Walter Bright 2007-09-07 19:31 ` David Kastrup 2007-09-07 20:49 ` Walter Bright 2007-09-07 19:41 ` Pierre Habouzit 2007-09-07 19:51 ` David Kastrup 2007-09-07 19:59 ` Pierre Habouzit 2007-09-07 20:40 ` Walter Bright 2007-09-07 20:56 ` Pierre Habouzit 2007-09-07 22:54 ` Walter Bright 2007-09-08 0:56 ` John 'Z-Bo' Zabroski 2007-09-08 6:36 ` David Kastrup 2007-09-19 19:56 ` Steven Burns 2007-09-07 3:06 ` Wincent Colaiuta 2007-09-07 4:06 ` Paul Wankadia 2007-09-07 4:30 ` Nicolas Pitre 2007-09-07 9:19 ` Wincent Colaiuta 2007-09-07 6:25 ` Andreas Ericsson 2007-09-07 10:56 ` Johannes Schindelin 2007-09-07 11:54 ` Andreas Ericsson 2007-09-07 12:33 ` Wincent Colaiuta 2007-09-07 12:55 ` Karl Hasselström 2007-09-07 13:58 ` Andreas Ericsson 2007-09-07 14:13 ` Wincent Colaiuta 2007-09-09 0:09 ` Andreas Ericsson 2007-09-07 16:09 ` David Kastrup 2007-09-07 11:30 ` Wincent Colaiuta 2007-09-07 8:36 ` Walter Bright 2007-09-07 9:41 ` Andreas Ericsson 2007-09-07 19:23 ` Walter Bright [this message] 2007-09-07 19:40 ` David Kastrup 2007-09-09 0:25 ` Andreas Ericsson 2009-09-17 16:23 ` Bernd Jendrissek 2007-09-07 11:52 ` Wincent Colaiuta 2007-09-07 19:25 ` Walter Bright 2007-09-22 16:52 ` Steven Burns 2007-09-07 6:47 ` David Kastrup 2007-09-07 7:41 ` Andy Parkins 2007-09-07 8:08 ` David Kastrup 2007-09-07 10:21 ` Johannes Schindelin 2007-09-08 0:32 ` Dmitry Kakurin 2007-09-08 6:24 ` David Kastrup 2007-09-08 23:25 ` Alex Riesen 2007-09-24 13:41 ` figo 2007-09-24 13:57 ` David Kastrup 2007-09-25 19:19 ` Steven Burns 2007-09-25 19:55 ` David Kastrup 2012-05-22 18:30 ` Syed M Raihan 2010-06-10 19:12 ` Ian Molton 2010-06-11 12:23 ` Jakub Narebski 2010-06-11 13:33 ` Dario Rodriguez 2007-09-05 15:27 ` Kristian Høgsberg 2007-09-07 10:47 ` Lukas Sandström
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org' \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).