Long term changes in audio roundtrip latency

The way that patch measures latency jumps between message and audio signal domains a few times (metro -> click~, adc~ -> edge~, bang -> count~ -> snapshot~). There could be variation here between the scheduler processing and the audio sample clock. It's better to measure latency purely in the audio signal domain. Here's a purely signal-domain measurement -- does this also show gradually increasing latency?

Thank you!
I definitely was not keeping enough stuff in the audio domain.
Trying yours now. I don't think I can do a 15 hour test today, we'll see what happens...

Well, I might try harder later but looks like the roundtrip time is rock steady when the test takes place in the audio domain.
I'm gonna investigate scheduler slop and where I might be introducing some sketchy audio/scheduler interactions.
Very helpful test Graham, thanks again.
For the record I started looking into latency bloat because last time the issue occurred I was able to document roundtrip times an order of magnitude longer than expected.

Following up.
I just left the system on for a couple days and the unexpected latency increase is back.
I was not running Graham's patch the whole time so I cannot determine hour-over-hour change.
Using Graham's patch I am now seeing roundtrip latency of ~14,500 samples/30+ MS with the following settings:
SR:44.1 IOVS 512 SIGVS 512 Overdrive on Parallel processing on.
Disabling/enabling Overdrive, SIAI, or Parallel processing does not change the roundtrip latency.
Quitting and restarting Max immediately resolved the latency, with roundtrip latency of ~1650 samples (seems about right for 2xvector+speed of sound from speaker to mic).
The always-on-patch uses jitter and MSP, and a lot of audio threads. Not sure how to narrow down whether this is to do with something I have done in the patching. But closing the always-on patch does not solve the latency; Max has to be quit. Does this indicate some kind of "memory leak" or other cumulative thing?
Any tips on how to troubleshoot this?

Bumping due to additional info below. Quick recap: the issue is very long (500 MS+) latencies developing when MSP audio is on for multiple days.
OS X 10.10.2, Max 7.0.3
I’ve had some time to further troubleshoot this issue and wonder if the following shed any light on the issue.
I decided to compare I/O latency through vst~ when one instance of vst~ is hosting Apple’s AUMatrixReverb and another is hosting a Lexicon PCM reverb.
To do this I modified Graham Wakefield’s Gen~ routine to compare sample delays of
1) a click~ passed through Gen~ with a single sample delay
2) a click~ passed through the AuMatrix Reverb then Gen~ with a single sample delay
3) a click~ passed through the Lexicon then Gen~ with a single sample delay
The plugins were set to 100% dry, 0 pre delay, 0.0dB gain.

Initial results showed the AuMatrixReverb having the same single sample delay as the unprocessed click~, and the Lexicon having a consistent 33 sample delay.
(sending the vst~ objects a bypass 1 message reduced the Lexicon to a 1 sample delay.)

This seemed unremarkable—Lexicon’s 33 sample delay is probably some internal buffer/whatever.

The patch sampled this delay time every second. Based on the experiences I’ve had I expected:
A) the Lexicon sample delay to increase either suddenly or hour-over-hour
B) the AuMatrixReverb and unprocessed click~ to remain stable

Instead, after running 24 hours all three sample delays were totally consistent.
But
OS X popped up a warning about Max.app exceeding memory limits. Upon investigation Activity Monitor showed Max using 64.44 GB Memory. (See MaxBigRAM.png) Max froze.
I decided that this may be due to using jit.cellblock to monitor the recorded sample delays, and asking jit.cellblock to refer to a too-large coll.
So
I removed it.cellblock and ran the patch again. After 14 hours Activity Monitor showed 39.69 GB Memory (See MaxBigRAM02.png)

Is this an issue related to Max? If this is some kind of "memory leak" how can I track down the source?

{
    "version" : "Version 7.0.3 (37355d2) (64-bit mac)",
    "platform" : "mac",
    "arch" : "x64",
    "osversion" : "Mac OS X Version 10.10.2 x86_64",
    "samplerate" : 44100,
    "iovs" : 128,
    "sigvs" : 128,
    "scheduler_in_audio_interrupt" : "off",
    "audio_drivername" : "Core Audio",
    "audio_driver_subname" : "",
    "license" : "permanent full",
    "machine_id" : " hi ”,
    "eventinterval" : 1,
    "overdrive" : "on",
    "mixerparallel" : "on",
    "mixercrossfade" : 0,
    "mixerlatency" : 30.0,
    "mixerramptime" : 10.0,
    "videoengine" : "avf",
}

FYI when I close the patch Max memory use remains high..this is the Activity Monitor after all patcher windows are closed.

If there's a memory leak, we need to eliminate all other possibilities. Could you run the test again, this time without any VST or AU plugins loaded, and without the coll writing, i.e. with the following patch?

(Because there's a fair chance that the memory usage is from the plugins themselves, or from the coll sorting/writing, etc.)

Graham, thanks for looking into this.
FYI I was just starting a process-of-elimination test, taking out one object at a time, first running a test without the Lexicon plug, two AUMatrixReverbs instead, and seeing the app memory steadily rise.
So, I'd suggest:
--The issue is not the Lexicon plug--
But sure, let's work the other way, from as few objects up. Process-of-nonlimination?
I will quit that and try the patch attached above. I wonder if you've tried the patch you just sent?

Hello Graham (or anybody), in a couple hours I'll be checking the memory usage of the patch Graham posted April 29.
I have a hunch it will be stable at about
Next I am thinking of trying this, with one instance of vst~. Does that seem reasonable: