←back to thread

191 points jwilk | 5 comments | | HN request time: 0.773s | source
1. drhagen ◴[] No.46230181[source]
If this gets wide enough use, they could add an optimization for code like this:

    n = 1000
    a = {}
    for i in range(n):
        a[i] = str(i)
    a = frozendict(a)  # O(n) operation can be turned to O(1)
It is relatively easy for the JIT to detect the `frozendict` constructor, the `dict` input, and the single reference immediately overwritten. Not sure if this would ever be worth it.
replies(1): >>46230599 #
2. _flux ◴[] No.46230599[source]
Wouldn't ref-counting CPython already know that a has a single reference, allowing this optimization without needing any particular smart JIT?
replies(3): >>46231093 #>>46231158 #>>46236475 #
3. zbentley ◴[] No.46231093[source]
I think GP was talking about optimizing away the O(N) call on the last line. The GC will take care of removing the reference to the old (mutable) dict, but constructing a new frozendict from a mutable dict would, in the current proposal, be an O(N) shallow copy.

There are also potentially other optimizations that could be applied (not specific to dict/frozendict) to reduce the memory overhead on operations like "a = f(a)" for selected values of "f".

4. zahlman ◴[] No.46231158[source]
First thought: I would very much expect it to be able to do this optimization given the similar things it does for string concatenation.

But actually, I suspect it can't do this optimization simply because the name `frozendict` could be shadowed.

5. tracnar ◴[] No.46236475[source]
Indeed, the Tcl implementation does this so e.g. `set d [dict] ; dict set d key value` can modify d in place instead of creating a copy (since everything is immutable).