Add an IDE storage service benchmark#39105
Conversation
|
@sharwell can you merge in? |
|
@sharwell @jinujoseph can we move forward on this? This is just a perf benchmark to help when changing the sql persistence layer. Thanks! |
|
@sharwell Can you please merge in? Thanks! |
sharwell
left a comment
There was a problem hiding this comment.
Looks good though I had a couple questions.
| return GetStorageWorker(solution); | ||
| } | ||
|
|
||
| internal IChecksummedPersistentStorage GetStorageWorker(Solution solution) |
There was a problem hiding this comment.
❔ Is there a reason this method is needed? I thought setting the solution size threshold and database location would be enough to avoid the use of NoOpPersistentStorage.
There was a problem hiding this comment.
Unfortunately no. There is also an additional check that the workspace has a valid solution-file. For an adhoc workspace this check fails and we don't create the db. I don't want to change anything in real code about htat just now.
|
|
||
| private static readonly byte[] s_bytes = new byte[1000]; | ||
|
|
||
| [Benchmark(Baseline = true)] |
There was a problem hiding this comment.
💭 I don't believe Baseline = true is required here.
| [Benchmark(Baseline = true)] | ||
| public Task Perf() | ||
| { | ||
| var tasks = new List<Task>(); |
There was a problem hiding this comment.
Can avoid a few unnecessary array allocations as the list grows.
| var tasks = new List<Task>(); | |
| var tasks = new List<Task>(1000); |
There was a problem hiding this comment.
This should probably get fixed since it's inside the benchmark measurement loop so it impacts the results. We don't have to avoid all allocations but this one is pretty easy.
| _useExportProviderAttribute.After(null); | ||
| } | ||
|
|
||
| private static readonly byte[] s_bytes = new byte[1000]; |
There was a problem hiding this comment.
❔ Do we have a way to get a distribution of the size of writes we expect to see for e.g. Roslyn?
There was a problem hiding this comment.
it depends on the index and if we're in teh building phase or not. indices are rewritten depending on how sensitive they are to checksum changes. So, for example, our syntactic indices are extremely read-heavy and light on writes (unless, of course, you do something to touch a ton of files on disk).
however, semantic indices are very write heavy as many changes can cause a cascading "recompute teh index" pass to happen when something changes.
Last time i looked into this there were patterns all over the place.
There was a problem hiding this comment.
I'm specifically interested in the size of the writes. We use an array pool for write buffers if the writes are less than 4K (with this benchmark fitting inside that pool), but we don't pool arrays for larger writes. I'm curious what size writes we have in practice.
This helps enable us to make changes to the storage service and ensure that we're not regressing perf.