viewmail-info
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VM] [XEMACS COMMIT] Be lazy converting markers to integers, bytecod


From: Aidan Kehoe
Subject: Re: [VM] [XEMACS COMMIT] Be lazy converting markers to integers, bytecode_{arithcompare, arithop}().
Date: Thu, 19 Dec 2013 17:58:27 +0000

 Ar an séú lá déag de mí na Nollaig, scríobh Stephen J. Turnbull: 

 > Aidan Kehoe writes:
 > 
 >  > I would like to move to returning markers in #'max, #'min when all
 >  > arguments are markers that point to the same buffer,
 > 
 > Are there efficiency implications to this?

Well, #'min and #'max will no longer be O(N) when all their arguments are
markers in the same buffer. (They will remain O(N * M) if any of the
arguments are *not* markers in the same buffer, where M is the number of
those markers.)

The reason this bit us with VM is that Kyle knew XEmacs well and wrote his
code to its strengths. And when Mule came along and changed an O(1)
operation to an O(N) operation, Kyle was no longer working on vm, and we
(the XEmacs people) have been looking at what actually was slow for us and
speeding that up. But VM was at the end of that queue.

 > What is the logic for returning markers (other than efficiency)?

My logic is (was) that calling code can probably handle them already, and
the performance implications of doing it are more in the direction of lesser
astonishment.

There are 238 calls to #'max or #'min in the packages that I cannot
programmatically rule out as returning a marker that will escape, out of 1.8
million lines of code.

 >  > See also the comments in the tests. It surprised me strongly that the
 >  > markers weren’t preserved with changes that should have kept the same
 >  > relative character count, but it’s a separate issue that needs separate
 >  > investigation.
 > 
 > Yeah, that sucks.  I would go farther than "surprising" and just say
 > that's a bug.  But fixing that efficiently is probably not easy.

I haven’t looked into it.

-- 
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]