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)
