[erlang-patches] erlang-patches Digest, Vol 35, Issue 3

[Scott Lystig Fritchie]

Björn-Egil Dahlberg <wallentin.dahlberg@REDACTED> wrote:

b-ed> I think that in order not to impact the performance of the lock
b-ed> free queue we cannot keep an updated record of the queue length
b-ed> around.  Another queue function could be implemented to count the
b-ed> length of queue when needed. An O(n) operation. 

That's what I was afraid of.  Something O(n) definitely wouldn't be
suitable for DTrace's purposes, e.g. trying to answer the question(*),
"what's the longest size of an async work queue in the last N seconds?"

Well, the R14B04 flavor of my DTrace patches is able to get the queue
length in O(1) time, so I guess that'll stay for now ... and create a
Christmas wish list item for the R-sooner-than-19 release.

-Scott

(*) Given the VM's mapping of file path -> async worker thread, and
given that typically work on file I/O-heavy applications, it would be
really nice to know how often high file I/O latencies are due to the bad
luck that many simultaneous file I/O operations for different paths
simply happened to all map to the same async worker thread.