odb: cache x/y grids in dbTrackGrid

[gadfort]

No functional changes expected.

Changes:

• caches the results of the x/y grids in dbTrackGrid, these rarely change and take a noticeable amount of time to compute on larger designs (from this weekends testcase, about 45 seconds was spent repeatedly calculating this value in PDN (of course that is an inefficiency there, but this solves it for all)). When the grid is modified the cache is cleared.
• make gui/pad/pdn use returned references to the grid vector.

[github-actions]

clang-tidy made some suggestions

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[maliberty]

Its not that much memory but you'll still pay the inefficiency once. If it is faster there may be no need to cache. There is no reserve call, no need to sort for a single pattern, even multi-pattern could be more efficient than an append and sort.

[gadfort]

@maliberty I'm not sure what you mean by faster? The memory is trivial, and the improvements you are suggesting can be implemented, in a different PR.

[maliberty]

By faster I mean efficient enough that no cache is needed. Caching tends to be a source of bugs so I avoid it if I can (for instance this PR missed create / destroy invalidation).

[gadfort]

On create, there is nothing to do (the grid vector would be empty, thus load loaded).
On adding pattern, the grid is cleared to ensure it would be created again if requested.
On destroy the object is destroyed along with its members.
I don't think there is any risk here of a invalid cache (if you see something that is missing specifically, then I can address that).

Allocating the memory over and over again is also not particularly efficient. In the profile, insertion still takes real time (at scale).

[maliberty]

You are making a copy here fwiw

[maliberty]

I think this is unnecessary but not worth arguing over.