When profile rows are fetched, they are first read in into the buffer of a fixed size (128 rows). Therefore, the first profile becomes visible to the consumer only after the buffer is full, or all the rows are read, whichever occurs first. In practice, this delays fetching of symbols for the profiles, as we get the partition ID from the profile entries.
For example, in the screenshot you can see that the resolver starts fetching data only after the profile row iterator finished. There were 43 rows, therefore profiles become visible to it only after all of them were read in into the buffer:
This is especially harmful with downsampled profiles, because they are quite big, and the number of rows is relatively low. I think it makes sense to reduce the buffer size to 32: it does not cause an increase in number of reads or anything like this, but if the buffer is too small, read ahead buffering might be inefficient.
When profile rows are fetched, they are first read in into the buffer of a fixed size (128 rows). Therefore, the first profile becomes visible to the consumer only after the buffer is full, or all the rows are read, whichever occurs first. In practice, this delays fetching of symbols for the profiles, as we get the partition ID from the profile entries.
For example, in the screenshot you can see that the resolver starts fetching data only after the profile row iterator finished. There were 43 rows, therefore profiles become visible to it only after all of them were read in into the buffer:
This is especially harmful with downsampled profiles, because they are quite big, and the number of rows is relatively low. I think it makes sense to reduce the buffer size to 32: it does not cause an increase in number of reads or anything like this, but if the buffer is too small, read ahead buffering might be inefficient.