[Freecol-developers] bidirectional relationships and performance

[Enrico Weigelt, metux IT consult]

Hi folks,


in many places we have (semantically) bi-directional relationships, eg.
diplomatic relationships, etc, which are currently implemented as lists
on only one side of the relationship, so when coming from the other
side we'll end up in full list scans. (eg. see ServerPlayer::csKill())

What do you think about implementing an index structure which can be
looked up from both sides (maybe double hashtables, etc) ?


--mtx

[Michael T. Pope]

On Fri, 9 Dec 2016 03:00:20 +0100

Post by Enrico Weigelt, metux IT consult
in many places we have (semantically) bi-directional relationships, eg.
diplomatic relationships, etc, which are currently implemented as lists
on only one side of the relationship, so when coming from the other
side we'll end up in full list scans. (eg. see ServerPlayer::csKill())

I fear I am beginning to repeat myself, but I really want to see more
justification that this is a problem. If you want to optimize, please
look at the hot spots, not ultra-rare cases like csKill.

Post by Enrico Weigelt, metux IT consult
What do you think about implementing an index structure which can be
looked up from both sides (maybe double hashtables, etc) ?

I think it would be harder to read. Lists are simple. Code simplicity is
valuable. Especially in a project where people wander in and out.

Besides, the player list is short... show me a list with >100 members and
you have an argument for a quicker data structure.

Cheers,
Mike Pope