Bug 30548 - [XA 5.1] ThreadPool.QueueUserWorkItem() takes several seconds to run the work item when the app uses Xamarin.Insights 1.10.2.110
Summary: [XA 5.1] ThreadPool.QueueUserWorkItem() takes several seconds to run the work...
Status: CLOSED DUPLICATE of bug 30567
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries (show other bugs)
Version: 5.1
Hardware: PC Mac OS
: --- major
Target Milestone: 5.1.4 (C5SR2)
Assignee: Marek Habersack
URL:
: 30471 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-05-28 13:14 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2016-01-25 21:11 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test case (31.54 KB, application/zip)
2015-05-28 13:14 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details
Diagnostic build output and logcat logs (47.41 KB, application/zip)
2015-05-28 13:15 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
CLOSED DUPLICATE of bug 30567

Description Brendan Zagaeski (Xamarin Team, assistant) 2015-05-28 13:14:37 UTC
Created attachment 11373 [details]
Test case

[XA 5.1] ThreadPool.QueueUserWorkItem() takes several seconds to run the work item when the app uses Xamarin.Insights 1.10.2.110


I am filing this bug to provide a precise starting point for the investigation of Bug 30471, including a minimal test case, steps to reproduce, and results.


Regression status: REGRESSION between XA 4.20.2.1 and XA 5.1.2




## Steps to reproduce

1. Build and run the attached test case in the "Debug" configuration on emulator or device.

2. Tap the button.

3. Wait for the "Thread run after" message to appear in the output.

4. Optionally repeat steps 2 and 3.




## Results


During the first several repetitions of steps 2 + 3, there is at least a 5 second delay before each thread starts.

(Note: across several trials I observed some variability in how many consecutive repetitions of steps 2 + 3 hit the problem. But in the large majority of cases the _first_ repetition _did_ demonstrate the problem.)

### Example output from XA 4.20.2.1 running on Android 4.1.2 physical device

> Thread run after 6094 ms
> Thread run after 5565 ms
> Thread run after 5946 ms
> Thread run after 0 ms
> Thread run after 5991 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms




## Expected results

All the threads start after less than 1 second.

### Example output from XA 4.20.2.1 running on Android 4.1.2 physical device

> Thread run after 46 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 217 ms
> Thread run after 0 ms
> Thread run after 0 ms
> Thread run after 0 ms




## Partial workarounds


### Option A: do not load Xamarin.Insights

In particular, comment out the following line:

> Insights.Initialize("ANY_NON-EMPTY_STRING", this);



### Option B: downgrade the Xamarin.Insights package to 1.9.1.107 

It seems that the older version of Xamarin.Insights avoids triggering this Xamarin.Android bug.




## Additional version info (brief)



### Android SDK

Android SDK Tools 24.2
Android SDK Platform-tools 22
Android SDK Build-tools 21.1.1



### Android devices

Xamarin Android Player 0.3.7 (1), Nexus 4 KitKat

LG Optimus L9, Android 4.1.2



### OS X 10.10.3

Mono 4.0.0 (detached/d136b79)


=== Xamarin Studio ===

Version 5.9.1 (build 3)

=== Build Information ===

Release ID: 509010003
Git revision: aad75a6e7e48f18120ce41f47d0ff2c6216f49c3
Build date: 2015-05-08 12:46:18-04
Xamarin addins: 1246b3044cbb7f56a217334f8fc5489ef8eefe3f
Comment 1 Brendan Zagaeski (Xamarin Team, assistant) 2015-05-28 13:15:27 UTC
Created attachment 11374 [details]
Diagnostic build output and logcat logs
Comment 3 Jonathan Pryor 2015-05-28 13:41:57 UTC
@Brendan: This change is possibly due to Referencesource migration.

I'm not sure performance changes should qualify as "regressions".
Comment 4 Marek Habersack 2015-05-28 13:49:57 UTC
@Brendan: can you check if the problem exists on the desktop mono (master) and xamarin.ios?
Comment 5 Brendan Zagaeski (Xamarin Team, assistant) 2015-05-28 14:16:32 UTC
Ah yup, the Referencesource migration sounds like a probable culprit. I will definitely take a try at reproducing on desktop Mono and XI, and I'll report back what I find.
Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2015-05-29 00:55:31 UTC
I was unable to reproduce on desktop Mono or on iOS. It looks like the problem is specific to how Xamarin.Insights continually reads from "/system/bin/logcat" via `Java.Lang.Process.InputStream.ReadAsync()` in the Android platform code.

This could be an error in the Xamarin.Insights client code (i.e., it could be hitting an unsupported or undefined behavior in Xamarin.Android with regards to how it's reading the logcat while the app is running), or maybe it is some sort of bug in Xamarin.Android. In any case, I have filed a non-public bug to discuss the nitty-gritty details of that more specific problem, so I will close this bug as a duplicate for now.

*** This bug has been marked as a duplicate of bug 30567 ***
Comment 8 Marek Habersack 2015-06-01 12:51:25 UTC
*** Bug 30471 has been marked as a duplicate of this bug. ***
Comment 9 Jeremy Kolb 2015-06-01 12:53:45 UTC
Can you make Bug 30567 public so those of us affected can track the progress?
Comment 10 Brendan Zagaeski (Xamarin Team, assistant) 2015-06-01 13:40:20 UTC
I will keep this bug public bug up-to-date with any relevant news from private bug 30567.
Comment 11 Jeremy Kolb 2015-06-03 13:36:01 UTC
@brendan.zagaeski@xamarin.com is this fixed in Xamarin.Insights 1.10.3?
Comment 12 Brendan Zagaeski (Xamarin Team, assistant) 2015-06-10 14:07:45 UTC
Apologies for the delay in reply. Yes, the problematic logcat reader was indeed disabled for the time being in Xamarin.Insights 1.10.3.
Comment 13 Brendan Zagaeski (Xamarin Team, assistant) 2016-01-25 21:11:03 UTC
## Status update from non-public Bug 30567

(For thorough bookkeeping.)

Today I have verified that the performance regression demonstrated by the test case on non-public Bug 30567 is resolved as of Xamarin.Android 6.0.

The original test case on this public bug (Bug 30548) uses an older version of the Insights library that appears to be incompatible with Xamarin.Android 6.0, so I was unable to verify that the precise original test case has also been fixed. But based on the verification of Bug 30567 I am satisfied that the root problem has been solved.


In short this bug can be considered resolved and closed.

Thanks!