Re: [Newbie Question] Magic Number's dangerous?

On 2005-11-26, Chris Smith penned:
>> On 2005-11-25, Thomas Hawtin penned:
>> > byte[] buff = new byte[8192];
>> >
>> > byte[] buff = new byte[SOME_BUFFER_LENGTH];
>
> Monique Y. Mudama <spam@xxxxxxxxxxxxxxxx> wrote:
>>
>> Seems like you're dodging the issue here by giving a poor example.
>> The fact is that you must have chosen 8192 for a reason, and that
>> reason can be documented with a well-chosen variable name.
>
> Nah, I don't see that that's necessarily the case. When choosing
> buffer sizes, it's generally a matter of taking a guess. Usually,
> the guess is a power of two, because it works better with MMU/paging
> architectures where memory is typically allocated in pages of a
> power of two in size. Tuning can be done later if it becomes a
> performance problem of some kind. If there's some other kind of
> ultimate method of calculating ideal buffer sizes, then most of us
> haven't yet been informed.
>
> I typically choose buffers of size 32768 unless I have some reason
> not to. Obviously, Thomas Hawtin commonly uses 8192. Why? No
> particular reason. If it starts mattering in a measurable way, then
> I'm sure they'll get tuned, and then a comment will be added
> explaining the method used to choose the buffer size and the
> observed consequences of making it too large/small.
>
> In any case, even if the buffer size is carefully tuned, I very much
> doubt that you could explain the method or logic behind the choice
> in a reasonable identifier name.

Sorry for the late reply.

What if you get run over by a bus? The next guy to look at your code
won't know if you chose 32768 because it's your favorite number or
because you found it to be the best via experimentation. So the new
guy will probably avoid touching the magic 32768, whereas at least a
comment that "I pulled this number from my orifice; feel free to tweak
as needed" would give the guy some insight.

And as soon as you find that you need to pass the buffer chunks around,
it's better to use a constant instead of hard-coding the number in
several places.

--
monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
.

Relevant Pages

  • Re: O_DIRECT question
    ... the disk isn't a good idea IMHO. ... There is a reason that read and write return the ... fsync between both sets of writes, but that will flush any other ... The large buffer size really has little to do with it, ...
    (Linux-Kernel)
  • Re: [Newbie Question] Magic Numbers dangerous?
    ... > reason can be documented with a well-chosen variable name. ... it's generally a matter of taking a guess. ... where memory is typically allocated in pages of a power of two in size. ... ideal buffer sizes, then most of us haven't yet been informed. ...
    (comp.lang.java.programmer)
  • Re: sharing memory with non-children
    ... > program that uses shared memory and semaphores to make a pseudo-pipe ... If you STREAM the data from one process to the another, ... necessarily need a big buffer. ... > is no good reason to do so. ...
    (comp.unix.programmer)
  • Re: viewing files in a directory
    ... PS - the reason I did show that is because you can take the prologue code ... before the do-while loop and make necessary adjustments for it to recursive ... > so you can give the buffer address. ...
    (microsoft.public.vc.mfc)
  • Very slow CD burning
    ... and I've got it running under scsi emulation. ... WARNING: Cannot set RR-scheduler ... cdrecord.mmap: WARNING: This causes a high risk for buffer underruns. ... Indicated writing power: 1 ...
    (Debian-User)