On Mon, 16 Aug 2010, David Golden wrote: > > I think I'm with Reini on this one. I'd rather keep it Windows-only until a > performance problem is documented elsewhere. It's been documented that the patch improves performance on FreeBSD by a *factor* of 160 for one particular test case, as well as a factor of 4 on Linux. In the meantime Wolfram has constructed another testcase where the patch improves performance on Linux by a factor of 45 (my system) to 230 (Wolfram's system). Granted, these are worst-case samples, but at least the first test program was derived from a real-world application: appending lots of small strings to an ever-growing large buffer. The performance improvements have only been observed with usemymalloc=n, bringing that case up to par with the usemymalloc=y case performance-wise. The usemymalloc=y case seems (as expected) unaffected by this change. So disabling the code for that case won't make a difference. I generally prefer to keep code as simple as possible though, so I'm not sure if the patch needs to be disabled for usemymalloc=y. This is more a philosophical than a technical issue. > It's easy to enable for other platforms when needed. So far the patch has improved performance for *every* platform malloc() it has been tried on. The only malloc() that doesn't improve by it is the Perl malloc from Ilya. > I'm open to people doing the research before 5.14, of course. :-) Given the way the algorithm works, and that it has shown to improve performance on Windows, Linux and FreeBSD I claim it is now time for the detractors to find a system where the change has any negative consequences. Cheers, -JanThread Previous | Thread Next