Mingyi Kang

> This looks like a smart little optimization. Have you done any benchmark to see if GETSET gets any faster or uses less CPU? The redis-benchmark did not test the...

> Regarding your benchmark, there is a risk Redis is faster than the benchmark script. You can check `top` to see if the benchmark script is the bottleneck. You can...

> Optimization and code to support it looks good to me, however other than the optimization this change also affects: > > 1. key hit and key miss statistics. the...

If `getset` aims for writing and does not affect the hits/misses stats (same as `incr` command), then we can remove those many modifications which aim to keep the stats. The...

Nothing was missed, you are right, I misunderstood and thought that we need to keep the original behavior. If it is better to consider getset as a write command, then...

Ok, wait for more feedback first.

Hello everyone, I'm new to NetworkX and really appreciate these amazing implementations! I think that for the all-targets case, there might be a simpler appraoch to optimize: we can record...

> I assume the motivation is that you'd like to get the "transformed" distances out, correct? Otherwise computing the "distances" of the unmodified paths is straightforward. > > I'm -1...

> What takes a long time for computing the length of a path. It should be fairly quick computationally. And NetworkX has a function to do it: [nx.path_weight](https://networkx.org/documentation/stable//reference/generated/networkx.classes.function.path_weight.html#networkx.classes.function.path_weight) > >...

> Thanks for your rewording of the OP. I now understand that this aims to allow folks to avoid creating the paths in the Djikstra part of the Johnson method....