Making the enumerators is a waste indeed, but for the particular code I commented on, that is, CLOSE_TASK3:
, the main problem isn't the time it takes to make the enumerators, at least not in general. The key issue with CLOSE_TASK3:
, which is implied by nnnik
's comment, but which you seem to have failed to realise, is that for every key which meets the condition (instr(...)
) you have to recheck the condition for all preceeding keys before finding the next match. Horror example, 10000 items, 5000 of them matches the condition, and they are all situated at the end of the list, the two-loop method makes two enumerators, 10000 checks of the condition and 5000 delete iterations, CLOSE_TASK3
makes 25 005 000
checks and 5001 enumerators. Here, the significant part isn't the enumerators, and the facepalm grows at a square rate.
In your test script, your redesign of the class is probably what I would have suggested. You are not using List
to store the name
, but you put it where it belongs
, and you do the (symbolic) clean up in __delete
and have the method del
only to clear the circular reference
. However, the benchmarking is flawed, I think I will use this for a new puzzle
: Puzzle 9: Release the bug.