odb: Add pointer caching to master terminal retrival

[jbylicki]

dbIterm::getMTerm() is a good candidate to add caching to the value being returned, as updates to the underlying dbMTerm structure are very infrequent. The function, while already optimized, is fairly expensive for a getter, and it's called very often.

Benchmarks of the 2_1_floorplan step:

nangate45/black_parrot

Branch	Min [s]	Max [s]	Mean [s]	Relative mean	Median [s]	Relative median
master	52.20	52.68	52.50 ± 0.20	1.04 ± 0.00	52.55	1.04
odb-add-mterm-caching	50.02	50.88	50.43 ± 0.33	1.00 ± 0.01	50.55	1.00

nangate45/ariane133

Branch	Min [s]	Max [s]	Mean [s]	Relative mean	Median [s]	Relative median
master	85.98	87.29	86.61 ± 0.47	1.07 ± 0.01	86.52	1.07
odb-add-mterm-caching	80.72	81.74	81.15 ± 0.35	1.00 ± 0.00	81.19	1.00

nangate45/ibex

Branch	Min [s]	Max [s]	Mean [s]	Relative mean	Median [s]	Relative median
master	28.93	29.01	28.97 ± 0.03	1.09 ± 0.00	28.98	1.09
odb-add-mterm-caching	26.41	26.80	26.56 ± 0.14	1.00 ± 0.01	26.50	1.00

asap7/ibex

Branch	Min [s]	Max [s]	Mean [s]	Relative mean	Median [s]	Relative median
master	33.30	33.58	33.41 ± 0.12	1.07 ± 0.00	33.33	1.07
odb-add-mterm-caching	31.02	31.41	31.16 ± 0.15	1.00 ± 0.00	31.09	1.00

[maliberty]

Iterms are the most numerous objects in the system. Adding a pointer will have a high memory cost

[jbylicki]

Although ibex is not the biggest design, it's viable to run under valgrind. The results showcase that the total size of allocations rose by about 0.1% and peak usage by about 1% (collected outside of valgrind due to high overhead from the tool).

Results:

asap7/ibex on odb-add-mterm-caching:

==775357== HEAP SUMMARY:
==775357==     in use at exit: 82,024,533 bytes in 438,805 blocks
==775357==   total heap usage: 58,604,363 allocs, 58,165,558 frees, 2,190,016,295 bytes allocated
==775357==
==775357== LEAK SUMMARY:
==775357==    definitely lost: 76,184 bytes in 653 blocks
==775357==    indirectly lost: 53,112 bytes in 1,269 blocks
==775357==      possibly lost: 21,747,206 bytes in 33,705 blocks
==775357==    still reachable: 60,148,031 bytes in 403,178 blocks
==775357==                       of which reachable via heuristic:
==775357==                         newarray           : 3,512 bytes in 2 blocks
==775357==                         multipleinheritance: 824 bytes in 2 blocks
==775357==         suppressed: 0 bytes in 0 blocks
==775357== Rerun with --leak-check=full to see details of leaked memory
==775357==
==775357== For lists of detected and suppressed errors, rerun with: -s
==775357== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Non-valgrind peaak memory usage: 184604KB

asap7/ibex on master:

==811821== HEAP SUMMARY:
==811821==     in use at exit: 82,023,509 bytes in 438,805 blocks
==811821==   total heap usage: 58,604,363 allocs, 58,165,558 frees, 2,188,685,375 bytes allocated
==811821==
==811821== LEAK SUMMARY:
==811821==    definitely lost: 76,088 bytes in 645 blocks
==811821==    indirectly lost: 53,472 bytes in 1,278 blocks
==811821==      possibly lost: 21,746,942 bytes in 33,704 blocks
==811821==    still reachable: 60,147,007 bytes in 403,178 blocks
==811821==                       of which reachable via heuristic:
==811821==                         newarray           : 3,512 bytes in 2 blocks
==811821==                         multipleinheritance: 824 bytes in 2 blocks
==811821==         suppressed: 0 bytes in 0 blocks
==811821== Rerun with --leak-check=full to see details of leaked memory
==811821==
==811821== For lists of detected and suppressed errors, rerun with: -s
==811821== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Non-valgrind peaak memory usage: 182756KB