Ticket UUID: | b9ecf3ce9801c480620f83b34110f808bd11affb | |||
Title: | [uplevel $list], [uplevel 1 $list] and generation of string representations | |||
Type: | Bug | Version: | 8.6.5 | |
Submitter: | pooryorick | Created on: | 2016-05-05 04:11:20 | |
Subsystem: | 18. Commands M-Z | Assigned To: | nobody | |
Priority: | 5 Medium | Severity: | Minor | |
Status: | Closed | Last Modified: | 2020-09-23 18:54:11 | |
Resolution: | Fixed | Closed By: | pooryorick | |
Closed on: | 2020-09-23 18:54:11 | |||
Description: |
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. | |||
User Comments: |
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. |
