Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c Subject: Re: Malloc Query Date: Thu, 19 May 2011 14:11:39 -0400 Organization: Friends of the Galactic Collective Lines: 78 Message-ID: References: <87aael3xw1.fsf@blp.benpfaff.org> <0.9e954b297cf63735a997.20110518193428BST.87zkmjuabv.fsf@bsb.me.uk> <0.3ac369f64d11bcd06d18.20110519002615BST.87ei3vtwtk.fsf@bsb.me.uk> <98a074c87051012-452fb@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx03.eternal-september.org; posting-host="OCGMVcahHOU+4XVlF+Y9Cg"; logging-data="15023"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX188KnBYUodSnyq8E2tCwfyn" User-Agent: nn 6.7.3 Content-Length: 3086 Cancel-Lock: sha1:nODdcvkKrChY2bwA3bv5ta6ZA4s= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4343 On Wed, May 18, 2011 at 09:38:05PM -0400, James Kuyper wrote: > On 05/18/2011 09:25 PM, Uncle Steve wrote: > > On Thu, May 19, 2011 at 12:26:15AM +0100, Ben Bacarisse wrote: > >> Uncle Steve writes: > >> > ... > >>> I haven't measured it's performance against malloc() just yet, but it > >>> must be something like an order of magnitude faster than malloc. > >> > >> I am guessing you don't have a background in the sciences! > > > > Not really. Science fiction doesn't really count. Real science is > > time-consuming, and I just don't have enough free leisure hours in the > > day. > > If you don't have sufficient spare time to test whether or not your > custom allocator actually significantly improves the speed of your > programs, you don't have enough spare time to justify wasting it > producing untested custom allocators. That's a little bit presumptuous. Are you suddenly in charge of my development schedule? I must have missed the memo. Anyways, I think it's valid to say that some things are understandable by 'inspection', as I think they say in some math texts. > ... > > Hey, the code I wrote there is almost trivial to test. I don't know > > why you're so keen to get numbers on it, > > He's not - the key point is that you SHOULD be. If it's indeed trivial > to test, you should have done so already. Until you have those numbers, > you can't be sure whether or not your custom allocator was a complete > waste of time. The one previous to that may have been, but I didn't test it either. Instead, I wrote the version I'm using now. BTW, I do all my code development in a very limited amount of free time. You seem to be saying that as I am talking about the algorithm in a public newsgroup, that I should have also proved it in the lab and in the field, not to mention publishing all the testing data and methodologies. As I mentioned previously I'm not a working scientist, even if I know some of what they do and how they go about it. > ... > > course I edited for brevity. In this newsgroup, when someone posts a > > few screens full of code it takes time to read it. I don't think it > > would have been better if I had posted the entire source file in this > > instance. > > Example code that has, at the very least, been compiled, and preferably > tested, wastes a lot less of a reviewer's time than code with a variety > of miscellaneous uncaught bugs. The reviewer has to waste time trying to > figure out whether those are actually bugs, or features. Are we 'reviewing' code in this newsgroup? I thought we were discussing it. > ... > > Oh, absolutely. Using integers as a sort of offset from a base is > > the kind of thing more common to assembly language programmers, but > > even in C it's a common idiom to use an array index, > > It's not as common as you seem to think. I don't really know how common it is, so you're already ahead of me on that score. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?