🚀 go-pugleaf

Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
:
: That's just the static code size. What about the total count of
: executed instructions? I bet that goes up quite a bit more. Each
: time you have to dereference a handle, you have to execute twice
: as many instructions. Chasing dynamic links becomes slower.
:

Nope.  Your "twice as many instructions" comment is BS.  You lock,
access as many times as you need, then unlock.  You don't have to lock
or dereference twice for each access.

: >
: >That says more about your skill as a programmer than it does about the
: >Mac's memory scheme.
:
: Not every programmer wants to go through blockhead exercises that have
: nothing to do with the computing task.
:

But they all have to.  It's called programming.  It's the "blockhead
exercise" that programmers have to do so that others can perform their
computing tasks.  LISP bigots will tell you that malloc() itself is a
"blockhead exercise".  Compared to all the crap you have to learn to write a
modern application, handles get lost in the noise.

:
: I wouldn't say that I am closed-minded person. Hell, I implemented the
: crap myself, foolishly thinking that heap compaction would be neat!
: After all, memory is a precious resource with which one must be
: very frugal. Once you use it up, ain't none left!
:
: After I saw what my favourite list, B+tree and hash-table module turned
: into when converted to use double indirection, I erased the project at
: once!  I went to the library and pulled out Knuth, which at once set me
: straight.
:

Perhaps you should have read the Knuth books *before* you wrote your
heap compaction algorithm.  There is no need to do double indirection
on every access.
--
Jerry J. Shekhel
jerry@cybercom.net