Do you think it's faster to do a stack scan on each in-place update than to update an "in play" count each time that stack gets updated?
Thanks, -- Raul On Tue, Jun 21, 2016 at 2:53 PM, Henry Rich <henryhr...@gmail.com> wrote: > There is a usecount on each value, but that doesn't help here, because the > usecount is not incremented when the value is referenced, but only when it > is assigned (it's too hard to change that, at least for now). > > But there is a stack of names that are 'in play' - have been referenced by > this or a higher-level sentence. The trick would be to look in this stack, > in higher sentences, to see if the name being assigned is in use. > > Since in-place update is not a guarantee, I think it could be documented > with a page describing what makes in-place update possible. I am hoping to > use in-place update much more than we have previously done, so such a page > would be needed anyway. It is a Coding Tip rather than a Language > Description. > > Henry > > > > On 6/21/2016 1:21 PM, Raul Miller wrote: >> >> That fix you describe seems reasonable - I think it winds up being an >> "in use counter" on each name which, in effect, caches the result that >> you would get by walking the stack counting references. >> >> Documenting this issue, however, probably warrants some thought. How >> do you explain to people that the same code will run quickly or slowly >> depending on the calling environment? Since "global" variable use is >> also a code correctness and design issue, I do not think the >> performance issue raised by fix you describe makes it be a bad >> language design decision (though of course there will be critics of >> any design decision). >> >> Anyways... a quick search suggests a few mentions which probably need >> elaboration on this subject (perhaps something like: "as of version >> ___ a problem was resolved where in place assignment conflicted with >> the dictionary definition. Note also that this means that if a >> sentence is using a name and calling some code which would otherwise >> have been doing an in place update of that name that in place >> assignment would be inconsistent for the caller and does not happen. >> This is both a performance and a code correctness issue." - but if >> someone could come up with a better phrasing, that would probably be a >> good thing). Here's the references I found which will eventually need >> updating: >> >> http://code.jsoftware.com/wiki/Vocabulary/curlyrt >> http://www.jsoftware.com/help/jforc/modifying_an_array_m.htm >> http://code.jsoftware.com/wiki/Vocabulary/SpecialCombinations >> http://www.jsoftware.com/help/jforc/performance_measurement__tip.htm >> >> Nothing is ever simple, which I guess is a part of why we put so much >> effort into trying to make things right... >> >> Thanks, >> > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
