Except you also reboot between each of those firmware updates too...
If there is a "strong correlation" why no speed improvement between:
I don't disagree that rebooting sometimes helps. I also don't disagree that some releases perform better than others. I am just pointing out that there isn't a "strong correlation" statistically speaking.
I have also noticed that rebooting a second time after the hub comes back up after a firmware update will improve performance in some cases. So I still think there is something there.
They're might be. 
My data doesn't show that, but every hub is different - different devices, different apps, different logging, etc.
I have almost no apps, and have description logging off on pretty much every device. My log file is only about 10 entries a day.
So there is a lot of variability in experiences. Just because I don't see it doesn't mean others don't. 
Hopefully some kind of soak test is part of the process in figuring out what is going on here. Test new features and bug fixes on hubs that get restarted as necessary, but before a major (non-hotfix) release goes out the door, let it run for a specified period in a test environment. Monitor performance but no rebooting allowed. This is SOP on the most of the beta programs I have participated in
I wouldn't bother to bring this up but although this problem (slowdown after XXX hours/days) has been officially acknowledged and is being addressed, I've never read confirmation that it has ever been reproduced by HE staff. Maybe I missed it? On the other hand we have received feedback HE developers do not see this issue on their own hubs.
Yet the beta invitations that just went out have not included 'my hub has slowdown issues after hours/days of runtime' as a criteria in soliciting participation. The only logical explanation is that a sufficient number in the current crop of beta testers fall into this camp. Fingers crossed....
+1 for a second reboot. I was expecting to see fastness after going to 2.2.3.118 but it wasn't until another reboot a day or so later that it really got fast.
The new release is out...tons of changes. Applied w/out any issues during the update. Does not include a Zwave radio update, so no need for the second step as w/the initial 2.2.3 update.
I had waited to update (on a c5) but with the new fix released I decided to run the update tonight. No issues as of yet. I turned off my daily reboot and will see how things go!
C-5
Had problems (slow hub) since months, without discovering the culprit(s). Rebooted the hub every day to have some tranquility.
Updated to 2.2.3.119 one week ago.
Since a week the rebooter app is disabled and I didn't change anything on my previous setup. I have a dashboard running 24/7. Node-Red is sending some data to the hub.
My system behaves normally, the dashboard speed is as expected and I have no visible delay on my rules (motion => lights). Hub watchdog :
So, for now, everything is OK.
BEFORE:
NOW:
C-5 Hub. with no Z-wave
Held off because of issues, but updated to 2.2.3.132 last night and everything seems snappier especially the dashboard.
Database went for 5m to 1m.
Thought I'd come back w/some generally good news after the 2.2.3.132 update. Overall my C7 hub appears to have been stable and automations and button>light controls seem to have been working reliably since yesterday afternoon.
I haven't been testing rigorously, but I haven't noticed anything that I've used failing, other than an automation (iris motion>ring spotlights turn on) that has not been reliable. There is one motion lighting automation that uses two iris sensors that my son was not sure was working as expected, but I haven't had time to test it.
Except for battery door sensors (which mostly show Failed or Not Responding, even though they are working fine), the Zwave Details page shows OK for all of my Zwave devices. My persistent failed ghost device is still there so overnight maintenance was not able to get rid of it.
So (knock on wood) this is better than the last few days when I was losing control of lights and having motion lighting that didn't work or was very sluggish. Definitely feeling much more glass half-fullish at the moment. 
Go team.
If your hub is anything like mine, after you get past the painful pairing process it runs really well.
Now that I'm done with pairing, I haven't had to do anything to my C7 hub and it has been working beautifully.
Fast, no errors, lovely.
(PS, everyone needs to quit doing Z-Wave repairs when they are not needed. )
Mine is the same.
The only beef I have is that Fibaro devices do not work very well.
I have some working but have had to put refesh() in my rules or there is no status update on change.
I had to put in Qubino relays to replace my 222's and 223's.
I now have a draw with Fibaro devices in waiting for some sort of fix.
You meant when they are not needed, I presume.
Otherwise I'm going to go off and do five Z-Wave repairs, so tell me quickly. 
Fixed. 
Anyway, zwave repairs are just a pet peeve of mine. Yes, the system should allow you to do them to your heart's content without causing issues - whether they are really needed or not. And we'll get there on the C-7 - I have no doubt there.
Someday maybe we will even have finer grained control over the route selection - there are mechanisms in the spec that allow the application side (hub in this context) to have some control over return device paths (in addition to the full control they have over hub to device communications). Not many hubs allow input to this/control over this though as users can screw up the mesh more than they help it if not done well / with some boundaries.
Paths that people think should be the best and most logical aren't always how the radio waves go/reflect/make it from point A to B... Or forcing a path can have other side effects in terms of overall mesh health, even if it makes one device path better.
But you never know what wacky cool stuff Bryan will come up with in the future! Probably stuff he hasn't even thought of yet.
I don’t know if you’ve used the Zone Motion (built-in app) yet, but I have found that with my ML instances that use more than 1 sensor, combining them into one virtual sensor with Zone Motion has made them reliable. You can also add contact sensors to the Zone by using the “Contact-Motion” app on Hubitat’s github.
Yup, that's a good idea. I actually already have the app set up, just didn't get around to enabling it for that automation. Thanks for the reminder...
Love the fact that I noticed the speed increase with the latest 2.2.3 version...and it seemed to help for sure...
isn't ANYONE going to mention the fact that for quite some time we were told it was bad apps/drivers and that the cause wasn't on the HE side? 
Either way I'm glad to see some progress forward.
True!!
Well, I think it was an AND not an OR.
There were (are, in some cases) app/driver issues AND there were (are, in some cases) hub issues.
I always thought of it such that it was a lot easier for end users to test the app/driver impact 1st (as they can be disabled, and is sometimes the actual issue) while Hubitat worked on the hub side of things that end users can't do.
It is absolutely still the case, we just made the platform more forgiving of bad apps and drivers 
Download the Hubitat app
