[dsdp-dd-dev] RE: [platform-debug-dev] RE: Memory ViewIMemoryBlock/Exten

["Williams, Ted" <ted.williams@xxxxxxxxxxxxx>]

Samantha,

"Alternatively, we can also define the pre and post buffer size based on
the window size.  If the window size is bigger, the rendering buffers
more memory.  When the window size gets smaller, the rendering buffers
less.
For example, we can define a rendering to buffer 25% of the window size"

I'm confident that the buffering solution you've implemented in the
table renderings is appropriate for debug use cases involving high
bandwidth target connections. In these cases, a handful of extra bytes
should create only a negligible impact on performance. However, for
debug scenarios involving target connections with high latency and low
throughput characteristics, it is difficult to justify unnecessary
reads, especially in circumstances where the buffers will be purged on
every suspend event. The rule of only reading the minimum amount of data
necessary to populate the user interface may need to be broken
occasionally, when practicability dictates, but without the rule, the
accumulation of non-essential target traffic creates a real performance
hit with slow connections.

I should emphasize that I am not lobbying for the
AbstractTableRenderings to be reworked for slow target connections. A
major goal of the new memory infrastructure was to allow for custom
renderings. It's a fair response to say we should provide our own
rendering. Since the IMemoryBlock/Extension cannot be resized, placing
the history logic in the view makes sense.

Thanks again for the help. Your explanations and work on the view are
appreciated.

ted