Performance issues

[admin]

Hi,

no, sadly you cannot revert the framework version - the code of SharpCap is compiled to expect version 8 for the new releases, so if you gave it version 7 instead then it would go 'bang!'.

You can make old/new testing easier - install the old version, copy the SharpCap install folder somewhere else on disk, then upgrade to new. You can then run the new version from the normal shortcut and the old from the copied folder and they will not interfere with each other.

I did a quick test yesterday of CPU usage with a Player One MarsC camera running at maximum frame rate on USB3 - the CPU usages for just watching the preview from the camera were basically identical between the older (4.1.11824) and newer (latest) version of SharpCap on my system.

Testing write speeds to disk is probably best checked using the 'Speed Test' button in the filename settings or the 'Test Camera 2 (High Speed)' as those reduce variability by having synthetic data. As far as I can tell nothing significant has changed in the relevant code recently.

Speeds when capturing in the mosaic - it would be worth checking the various things that might be different when running the mosaic to see if they impact things. Differences include

* The crosshair reticule may be left active during the captures to allow you to see frame positioning - on most systems this has neglible impact, but may have some impact on a low power system
* Various other windows are visible over SharpCap while mosaic capturing - again these may have an impact if resources are stretched.

Essentially, since I can't reproduce any similar issues, and can't see any relevant code changes that might explain what is going on, I can't do much without a very clear set of steps to reproduce the exact minimal situation needed to trigger a slowdown.

cheers,

Robin

[astra]

1. Could you possibly compile a special build against net7 for me to test? This would help us determine whether the issue is with the framework or recent changes. Since you mentioned there are no recent changes, it might be related to the framework, and we need to confirm that.
2. The performance was not the best, but now it is even worse. Today I specifically tested two versions. A simple quick capture has lower framerate than in previous version.
3. I found some profilers for .NET, but they are paid. As I'm not a .NET developer, do you know of any good open-source profilers?
4. The write speeds are similar in both versions, so it seems the decreased disk write speeds might be due to higher CPU usage in the new version.
5. If I disable flat fps increases in both versions, but it is less prominent in the new version. Closing histogram also helps a but but not that much

Here's the thread CPU usage data. I'm not sure why I see the svbony SDK, star detector, and qhyccd. Maybe there's room for optimization elsewhere. Also, there are two threads calling PlayerOneCamera.dll!POAStopExposure, which seems unusual.

For now, I'll have to stick with the old version as the new one is quite difficult to use.

Code: Select all

7992, 15.17, 1,218,242,552, wpfgfx_cor3.dll!MilContent_DetachFromHwnd+0xe10, Normal, 
1144, 12.95, 1,039,519,148, PlayerOneCamera.dll!POAStopExposure+0x3b68c, Normal, 
7148, 12.53, 1,005,785,656, coreclr.dll+0xb4b30, Normal, 
7672, 10.23, 821,187,516, coreclr.dll+0xb4b30, Normal, DefaultDomain
6684, 9.11, 731,445,184, coreclr.dll+0xb4b30, Normal, 
4836, 5.85, 469,967,618, SharpCap.exe+0x11360, Normal, DefaultDomain
4628, 3.38, 271,296,936, coreclr.dll+0xb4b30, Normal, 
4516, 1.37, 110,036,274, coreclr.dll+0xb4b30, Normal, 
2540, 1.15, 92,284,438, coreclr.dll+0xb4b30, Normal, 
3204, 0.18, 14,606,978, coreclr.dll+0xb4b30, Normal, DefaultDomain
4404, 0.16, 12,944,356, coreclr.dll+0xb4b30, Normal, DefaultDomain
3128, 0.13, 10,357,254, coreclr.dll+0xb4b30, Normal, 
7428, 0.12, 9,916,256, coreclr.dll+0xb4b30, Normal, 
5688, 0.11, 8,562,292, coreclr.dll+0xb4b30, Normal, 
4788, 0.03, 2,672,562, coreclr.dll+0xb4b30, Normal, 
992, 0.02, 1,980,642, coreclr.dll+0xb4b30, Normal, 
6404, , 681,020, coreclr.dll!MetaDataGetDispenser+0x3970, Highest, 
3816, , 551,428, coreclr.dll+0xb4b30, Normal, 
3272, , 405,440, coreclr.dll+0xb4b30, Normal, 
8024, , 327,014, PlayerOneCamera.dll!POAStopExposure+0x3b68c, Normal, 
4332, , 70,260, coreclr.dll+0xb4b30, Normal, 
7068, , 64,284, coreclr.dll+0xb4b30, Normal, 
3632, , 46,832, coreclr.dll+0xb4b30, Normal, 
7924, , , mscorwks.dll!GetMetaDataInternalInterfaceFromPublic+0x8be0, Highest, DefaultDomain
7768, , , SVBCameraSDK.dll!SVBRestoreDefaultParam+0xa3540, Normal, 
7528, , , msvcrt.dll!endthreadex+0x30, 5, 
7044, , , coreclr.dll+0xb4b30, Normal, 
6688, , , SharpCap.StarDetector.dll!EstimateNoise+0x353770, Normal, 
6624, , , SVBCameraSDK.dll!SVBRestoreDefaultParam+0xa3540, Normal, 
6532, , , combase.dll!CoTaskMemRealloc+0x10a0, Normal, 
6516, , , SharpCap.StarDetector.dll!EstimateNoise+0x353770, Normal, 
6200, , , coreclr.dll+0xb4b30, Normal, 
6196, , , GdiPlus.dll!GdiplusStartup+0x1e60, Normal, 
5496, , , mscorwks.dll!StrongNameErrorInfo+0x2c1c, Normal, 
5452, , , coreclr.dll!coreclr_execute_assembly+0xa760, Normal, 
5416, , , coreclr.dll+0xb4b30, Normal, 
5316, , , SharpCap.StarDetector.dll!EstimateNoise+0x353770, Normal, 
5028, , , coreclr.dll+0xb4b30, Normal, 
4708, , , PenImc_cor3.dll!RaiseResetEvent+0x3780, Normal, 
4644, , , qhyccd.dll!equalizeHistogram+0x264500, Normal, 
4504, , , SVBCameraSDK.dll!SVBRestoreDefaultParam+0xa3540, Normal, 
3940, , , combase.dll!CoTaskMemRealloc+0x10a0, Normal, 
3620, , , SharpCap.StarDetector.dll!EstimateNoise+0x353770, Normal, 
1896, , , ntdll.dll!EtwNotificationRegister+0x2d0, Normal, 
1676, , , ntdll.dll!EtwNotificationRegister+0x2d0, Normal, 
1124, , , SharpCap.StarDetector.dll!EstimateNoise+0x353770, Normal, 
1120, , , coreclr.dll+0xb4b30, Normal, 
592, , , SVBCameraSDK.dll!SVBRestoreDefaultParam+0xa3540, Normal, 
264, , , coreclr.dll!coreclr_execute_assembly+0x11d20, Normal, 

[astra]

Again, the issue is more complex than just .net. Sharpcap is extremely slow. Here is a screenshot of SC cpu load during autofocus, 73%! And cpu load of firecapture without saving and with saving of files, 14% and 34%. Fundamentally, something is wrong with SharpCap.
Yeah, I can get CPU load in Firecapture up to 60-70% but only if I enable Gamma. In SharpCap, I don't see any gamma setting for this camera. Is there some internal processing? Like implicit histogram stretching at zero values, so that full processing of each frame is done, but the image is the same

[admin]

Hi,

the focus score result is expected - with that tool active, SharpCap is calculating a contrast score for every frame (or at the very least is spending CPU time to almost continually be calculating focus scores), so the CPU will rise significantly.

Having thought about this a bit more, I've remembered that my all sky camera is a Celeron J3160 @1.6Ghz with just 4Gb memory - makes yours look like a supercomputer... I will test this out with the old and new versions in simple tests like just running the camera, etc, and see if I can spot anything.

cheers,

Robin

[astra]

>the focus score result is expected - with that tool active, SharpCap is calculating a contrast score for every frame (or at the very least is spending CPU time to almost continually be calculating focus scores), so the CPU will rise significantly.

Please pay attention to the ROI of focus are and FireCapture. During full image capture, SharpCap has the same 85%+ cpu load.

Today I was using FireCapture, and it was a pleasure to have responsive mount controls

[admin]

Hi,

I am still struggling to see any difference between the 3.1.12196 and newer versions - I ran both yesterday side-by-side on my Celeron J3160 with a USB3 camera and achieved the same frame rates at roughly the same CPU loads (the CPU load was a bit variable, particularly the load for the remote desktop software).

If I can find the difference between the two versions in my testing then I have a good chance of tracking it down and working out why, but right now, everything I do gives the same results on the two versions. I will keep testing.

cheers,

Robin

[astra]

Robin, performance difference in my case is the consequences of the global issue. SharpCap is extremely slow overall, that is why even minor changes influence CPU load that much. Please check FireCapture CPU load during capture — not more than 30%. I never get these values in SharpCap in preview mode, even with a smaller (!!) ROI.

[admin]

Hi,

right now I am aiming to find/understand and ideally fix the regression that you reported after build 12196. If I can find usability issues due to slowness then I will do my best to fix those too, but currently I'm not seeing either a regression or significant usability issues on my J3160 Celeron system.

As to the firecapture comparison - from the screenshots it looks like firecapture is running at 5FPS which will reduce CPU usage massively. SharpCap is capturing from the camera at 140fps in the screenshots, and will be displaying at a variable rate of up to 30fps (this is dynamically adjusted by SharpCap - reducing it if the CPU load seems to be getting too high). If you want, you can use the 'Frame Rate Limit' control in SharpCap to reduce the frame rate in a similar way to the '5FPS' setting you have in Firecapture.

cheers,

Robin

[astra]

Exactly what I'm talking about. That option works great in Sharpcap for display AND for capturing/writing image files. So with this option enabled, I get 5fps writing speed. Unlike Firecapture. In FC I can set the limit to 5fps in preview, but the writing speed would be my maximum 80 fps, that is why FC is so responsive. There is even an option in FC to limit preview to 3fps while writing.

As for performance degradation, you can send me a debug build compiled against net7. I'll do tests to compare it to net8.
But that would be nothing important if we had proper display/capture fps limiter

[admin]

Hi,

that's all meant to be automatic - SharpCap monitors the amount of CPU being used and tries to ensure at least 20% is available for user UI interactions - automatically reducing the display frame rate if necessary to keep things responsive. You can see it in some of the logs you sent with performance tracing turned on

Code: Select all

Verbose	16:43:52.400235	#25	Performance : Load measurement is 0.830, TargetFrameRate is 19.88, Displayed Frame Rate is 20.02, Displayed 26.7% of recent frames

If the load measurement gets above about 0.75 (75%) then the TargetFrameRate drops down from the default of 30fps and can go as low as 1fps if necessary to keep the load under control. THe higher the load measurement goes (or the longer it stays above 0.75), the more the frame rate gets pulled down, so it should all be self-adjusting (and usually is).

The actual load measurement is the higher of total CPU usage fraction and a measure of the usage of the CPU in the user-interface thread of the application, so neither of those should go above 75% for long without the frame update rate dropping to try to bring them down. Of course if something other than displaying frames is eating all the CPU, that can't be helped.

I had to scan through your logs quite a lot to find the line above where the load was high enough to start dropping the display frame rate, so it seems that the measurement of load is rarely hitting the threshold level for performance scaling for you. That kind of hints to me that the measurement is now missing something important (some other bottleneck in performance). The only thing I can think of is the wpfgfx_cor3 thread in your ProcExp snapshot. Not sure if I can get info from that into my load measurement or not...

What I will do for now is make two hidden settings

1) A way to adjust the target CPU load level from the default 0.75
2) a way to turn on a small window that shows real time monitoring of the measured load and the frame rate response to it.

This should let us learn a bit more and find out if a lower target load level helps significantly. If I can work out how to monitor the wpfgfx_cor3 thread (that's the one that actually updates the display - unfortunately created behind the scense by the framework I am using) then I will try to monitor that.

cheers,

Robin