|Title:||[uplevel $list], [uplevel 1 $list] and generation of string representations|
|Submitter:||pooryorick||Created on:||2016-05-05 04:11:20|
|Subsystem:||18. Commands M-Z||Assigned To:||nobody|
|Status:||Closed||Last Modified:||2020-09-23 18:54:11|
|Closed on:||2020-09-23 18:54:11|
The following script causes a string representation to be generated for each
item in the list passed to
The generation of string representations for items in such a list could have a significant unexpected performance/memory impact.
Ticket 1017884 is related, but this one-argument case could probably be fixed without the backward-incompatible change suggested in that ticket, since the single argument can be assumed to be the script to be evaluated.
pooryorick added on 2020-09-20 13:47:58:
This tradeoff has been mitigated by only checking list length if there is no string representation. This covers the bytecode case, which is probably the most important one. See [76da711d7172c54a]. It could be further mitigated by checking for a list or dict intrep first, and then ultimately by writing the TIP that would make the whole check unnecessary.
dgp added on 2020-09-19 16:32:01:
Effect of this patch is to avoid string generation for the particular case of a pure list with no explicit level argument. Tradeoff is the shimmering generation of a list representation for values that came in with other intreps. Might mean loss of bytecode. Or fragile intreps. Or expensive ones. It's a lot easier to train coders to include the explicit level argument than to have mercurial performance dances like this.
pooryorick added on 2020-09-19 14:34:37:
Fixed in [d67c23f6d1422fcf] for core-8-6-branch.
pooryorick added on 2020-09-19 14:15:40:
Fixed in [45569c7084346632] for core-8-barnch.