Closed performanceautofiler[bot] closed 2 years ago
Tagging subscribers to this area: @dotnet/area-system-text-json See info in area-owners.md if you want to be subscribed.
Author: | performanceautofiler[bot] |
---|---|
Assignees: | - |
Labels: | `area-System.Text.Json`, `tenet-performance`, `tenet-performance-benchmarks`, `refs/heads/main`, `RunKind=micro`, `Windows 10.0.19041`, `Regression`, `CoreClr` |
Milestone: | - |
I see no plausible libraries changes in this interval. Moving to VM per suggestion above, but it could be something else.
The System.Text.Json.Document.Tests.Perf_EnumerateArray regression isn't from the https://github.com/dotnet/runtime/pull/65738, it has occurred two days before that change went in.
Ah yes, Hashset and Enumerate using indexer commit range -- https://github.com/dotnet/runtime/compare/a1bc0f34fc8ad77c31a1682841d92dbb20e39dd8...5371203d5820a21922357e954e8c43eb4b76fd1d (includes #66456, which might be totally innocent still)
enumerate array commit range: https://github.com/dotnet/runtime/compare/6bf873a991bcae3f80f5de155a594cefc8824eea...bc5e386676ec5c806eef78d5fa754f1eadfe28c2. The plausible candidate there is (https://github.com/dotnet/runtime/pull/66618 (cc @AndyAyersMS ?)
@DrewScoggins it seems the 3 regressions in this issue occurred across 2 different intervals so ought to have 2 issues. analysis script glitch maybe?
I also notice that the commit range above (eg., the first one) is 17 commits, but from the graph, I think it should span only 8 commits.
Yeah, in general the auto-filer can do a good job of putting changes together that happened at the same time. Sometimes however, the actual point that the changepoint algorithm picks is several points off from where the actual changepoint is. This is an underlying weakness inherent in the algorithm. Normally, when we do the triage we try and make sure that only issues that match together end up in the same place, but this one slipped through.
The second piece is that because of this underlying weakness in the algorithm I make the diff link a commit earlier and later then the tool discovers to make sure that we increase the odds of the offending commit being in that range.
That's interesting. I'm curious what algorithm you use, etc-- is there a repo somewhere? This one on the face of it seems like an "easy case". (I know it's a hard problem and don't pretend to be able to do better)
OK I'll break the 2nd one out into its own issue.
It is checked into an internal repo, but I will put the relevant code here. You will also want to take a look at this package, ruptures, as it is the one we use for the changepoint analysis. You will also find linked there a good paper on changepoint analysis as a field of study. I used that one pretty extensively when I was first building this.
import numpy as np
import ruptures as rpt
import sys
data = open(sys.argv[1], ""r"").read()
points = data.split(',')
for i in range(0, len(points)):
points[i] = float (points[i])
points = np.concatenate([points])
algo = rpt.Pelt(model=""mahalanobis"", jump=1, min_size=3).fit(points)
results = algo.predict(pen=4*np.log(len(points)))
print(results)
Perf_Version.TryFormat2 regression on windows-x64
is this still an issue? from @janvorli comment this is not related to VM changes.
@DrewScoggins is this issue actionable? Based on the charts this looks like its within the range of what things were in 6?
I am closing this as not-actionable at the moment.
`### Run Information
Regressions in System.Text.Json.Document.Tests.Perf_EnumerateArray
EnumerateArray- Duration of single invocationmoved to https://github.com/dotnet/runtime/issues/67176](<https://pvscmdupload.blob.core.windows.net/reports/allTestHistory/refs/heads/main_arm64_Windows 10.0.19041/System.Text.Json.Document.Tests.Perf_EnumerateArray.EnumerateArray(TestCase%3a%20Json400KB).html>)Test Report
Repro
Run Information
Regressions in System.Collections.ContainsTrue<Int32>
Test Report
Repro