Bug 19745 - Performance issue on HTC One for Xamarin.Android app, but not with the same done in Java.
Summary: Performance issue on HTC One for Xamarin.Android app, but not with the same d...
Status: RESOLVED ANSWERED
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.12.3
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
: 19744 46500 ()
Depends on:
Blocks:
 
Reported: 2014-05-13 18:34 UTC by Jon Goldberger [MSFT]
Modified: 2016-11-18 03:57 UTC (History)
10 users (show)

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


Attachments
logcat from device with slow performance issue (448.27 KB, text/plain)
2014-05-13 18:34 UTC, Jon Goldberger [MSFT]
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:
RESOLVED ANSWERED

Comment 1 Jon Goldberger [MSFT] 2014-05-13 18:38:36 UTC
From case:

I have a performance issue with HTC One. When using a Xamarin.Android application using the high level screen layout (seen below) of controls the screen start to process everything very slow. I created a Java/Android app in IntelliJ with the same visual layouts and adapters and that application didn't have the performance issue that was seen with the Xamarin project.

Do you know of any open performance issues with the HTC One?

High level screen layout:
SwipeRefreshLayout
ListView - Used for grouping images into rows.
TextView - group description
HorizontalListView - Cheesebaron control used for horizontal scrolling of images
LinearLayout - orientation horizontal
ImageView - source loaded via UniversalImageLoader
ImageView - loading a vertical divider drawable
--------------------------------------------------------------
More info and version information:

Here is a sample project [link in above private comment] that contains a nav menu with 4 options to mimic our production app. Nav2 option is the only one populated with the layout in our app that has the performance issue.

We have only seen this issue on the HTC One device to report this issue.
Here is a full list of devices that we have had install our app during our testing phase.

google|Galaxy Nexus
google|Nexus 4
google|Nexus 5
htc|EVO
htc|HTC6525LVW
htc|HTCEVODesign4G
htc|HTC One
htc|HTCONE
htc|HTC One_M8
lge|LG-LS970
lge|LG-LS980
lge|LG-P769
lge|VS980 4G
motorola|DROID RAZR
motorola|XT1032
motorola|XT1056
motorola|XT907
samsung|SAMSUNG-SGH-I317
samsung|SAMSUNG-SGH-I337
samsung|SAMSUNG-SGH-I537
samsung|SAMSUNG-SGH-I577
samsung|SAMSUNG-SGH-I747
samsung|SAMSUNG-SM-N900A
samsung|SCH-S738C
samsung|SGH-T989
samsung|SGH-T999
samsung|SM-N900P
samsung|SM-N900T
samsung|SPH-D710
samsung|SPH-L710
samsung|SPH-L720
samsung|SPH-L900
sprint_lge|LG-LS840
tmous|HTC Sensation 4G
tmous|HTC VLE_U
Verizon|SCH-I535
Verizon|SCH-I545
Verizon|SCH-I605
Verizon|SM-N900V
verizon_wwe|ADR6410LVW


Version info:

=== Xamarin Studio ===

Version 4.2.4 (build 35)
Installation UUID: 1100c63d-1d86-404f-9f7f-f58579095b0f
Runtime:
Mono 3.2.6 ((no/9b58377)
GTK+ 2.24.23 (Raleigh theme)

Package version: 302060000

=== Xamarin.Android ===

Version: 4.12.3 (Business Edition)
Android SDK: /Users/jdenney/Library/Developer/Xamarin/android-sdk-mac_x86
Supported Android versions:
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
4.0 (API level 14)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Apple Developer Tools ===

Xcode 5.1.1 (5085)
Build 5B1008

=== Xamarin.Mac ===

Xamarin.Mac: Not Installed

=== Xamarin.iOS ===

Version: 7.2.1.42 (Starter Edition)
Hash: 773c77c
Branch:
Build date: 2014-04-18 15:39:16-0400

=== Build Information ===

Release ID: 402040035
Git revision: 1173cb1c45bc56cb702e82cd21a7c9d0cea4acbf
Build date: 2014-04-17 13:45:52-04
Xamarin addins: 53bde0041263928e8bd64686f5ca5a8e4338dd76

=== Operating System ===

Mac OS X 10.9.2
Darwin [hostname redacted] Darwin Kernel Version 13.1.0
Wed Apr 2 23:52:02 PDT 2014
root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
Comment 2 Prashant manu 2014-05-14 00:05:48 UTC
*** Bug 19744 has been marked as a duplicate of this bug. ***
Comment 3 narayanp 2014-05-14 05:32:06 UTC
I have checked this issue with HTC one V. I am also seeing performance issue on this device. Using the attached sample when I click on Nav2, It takes time to upload images compare to other devices.

X.S 4.2.5(Build 0)
Git revision: 95ac543f224a70960a9ab71e24ce341eb87de06f
X.Android 4.12.3-3

Android Log: https://gist.github.com/saurabh360/c2ddc247a5a665dc05c4
adb log: https://gist.github.com/saurabh360/017d090e90fde9aaf3b5
Comment 4 Jason Denney 2014-05-14 11:10:31 UTC
Here are the results from: adb shell cat /system/build.prop | grep "product"

This is from the first hands on experience we had with the performance issue.

ro.product.locale.language=en
ro.product.locale.region=US
ro.product.name=HTCOneM8vzw
ro.product.model=HTC6525LVW
ro.product.brand=htc
ro.product.name=HTCOneM8vzw
ro.product.device=htc_m8wl
ro.product.board=MSM8974
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=HTC
ro.product.locale.language=en
ro.product.locale.region=US
# ro.build.product is obsolete; use ro.product.device
ro.build.product=htc_m8wl
ro.product.version=1.55.605.2
ro.product.display_resolution = 5 inch 1080p resolution
ro.product.bluetooth=4.0
ro.product.main_camera = HTC UltraPixel Camera
ro.product.front_camera = 5M
ro.product.hwreset = 1
ro.product.hwreset.timer1 = 6
ro.product.hwreset.timer2 = 9
ro.product.ram = 2GB
ro.product.wifi = 802.11 a/b/g/n/ac

developer options:
Show layout bounds: off
Show screen updates: off
Animation scale: 1x
Comment 5 Jason Denney 2014-06-04 14:21:54 UTC
Has there been any new findings to this?
Comment 6 Jonathan Pryor 2014-06-09 14:10:50 UTC
@Jason: I don't have an HTC one.

That said, could you please state how you're observing this? What should I tap/scroll/etc. to attempt to see the performance issue? What IS the performance issue? Bad scrolling? Bad downloading? Not seeing anything at all when there should be something?

For example, when I launch the app it launches MainActivity, which is only shown for less than a second before it's replaced by a Fragment with "Nav 1" as the active view, which appears to be empty. I then tap the "hamburger" icon, which shows a menu allowing selection of Nav 1 through Nav 4. Nav 1, 3, and 4 all appear empty.

Selecting Nav 2 shows a variety of images. Scrolling is "weird", in that if I scroll to the top or bottom scrolling stops immediately, but if at the top I try to scroll "above the top" the contents are "pulled down", a'la iOS, which is rather odd to see on Android. There is no equivalent at the bottom of the list. Each row also allows scrolling horizontally, which is occasionally hard to trigger as my efforts frequently make the screen scroll vertically. When I hit the end of a horizontal/row list, it stops suddenly, more or less as I'd expect, though with no actual feedback that I'm at the end of the list, making me wonder if the app was stuttering the first time I did it.

Looking closer, it seems that _sometimes_ when I horizontally scroll a row it stutters slightly, but it might be my imagination; I'm not sure.
Comment 7 Jason Denney 2014-06-09 14:27:07 UTC
narayanp on 2014-05-14 05:32:06 EDT had reported seeing the performance issues with testing on multiple devices.

However Nav 1, 3, & 4 are left blank as those are just place holders for how our application navigation is handled.
The pull down to refresh action is becoming common and is a Android Support Tools released control and is used in a number of Google released applications and is making the design patterns more blurred between iOS and Android to more mobile design.  However design of the application isn't the concern of the support request as the Xamarin App has the performance issue where as a Java based Android app created with IntelliJ does not see the same performance issue.

The issue is observed by navigating to Nav 2 screen.  Once on Nav 2 the 2nd and 3rd rows on the vertical list both have approx 10 items with around 3 visible on the screen at the time.  Under normal performance the horizontal scrolling of those rows is smooth and can scroll from end to end very quickly with a fast flick.  However on 4 different HTC One's (2 M7's and 2 M8s) the scrolling distance is held properly and does eventually process correctly however the scroll animation for the rendering appears to be running at about 5fps vs 30fps however it's not dropping frames so the animation now takes a tremendous amount of time longer.
Comment 9 Peter Collins 2014-09-05 16:02:22 UTC
After an afternoon of profiling and investigation we're still unsure as to what is causing this performance degradation on the HTC One.

Here's a comparison of profiler results, one from an HTC One, and the other a Nexus 4: https://gist.github.com/pjcollins/1690bf6c0790e8d5073a

It appears that average execution time is faster on the HTC One versus the Nexus 4, however the HTC One's performance is much, much worse. It's also clear that the system time, and average cpu load are much higher in the case of the HTC One, what's still unclear is why.

To provide a little more information, I was seeing a very dramatic performance degradation immediately upon clicking the navigation drawer item in the top left, regardless of which item was selected. Navigating to the 'Nav 2' screen was not needed in my case, as the 'drawer open' and 'drawer close' actions were extremely slow when selecting any of the four Nav items. The Choreographer also made it very apparent that a large number of frames were being skipped right from the get-go, not only after navigating to 'Nav 2'.
Comment 10 Mark Probst 2014-10-16 10:01:09 UTC
Looking at the profiler results there doesn't seem to be a significant difference between what managed code is doing between the two devices, but there's a huge difference in time spent in the kernel and the system load.

Nexus 4:

	Mono System:
		User Time                      : 5590.000ms
		System Time                    : 2280.000ms
		Total Time                     : 11180.000ms
		Working Set                    : 123375616
		Private Bytes                  : 57712640
		Virtual Bytes                  : 971722752
		Page Faults                    : 69976
		CPU Load Average - 1min        : 1.270000
		CPU Load Average - 5min        : 0.880000
		CPU Load Average - 15min       : 0.700000

HTC One:

	Mono System:
		User Time                      : 6040.000ms
		System Time                    : 71630.000ms
		Total Time                     : 12080.000ms
		Working Set                    : 147554304
		Private Bytes                  : 71880704
		Virtual Bytes                  : 1021452288
		Page Faults                    : 2073732
		CPU Load Average - 1min        : 3.520000
		CPU Load Average - 5min        : 22.150000
		CPU Load Average - 15min       : 43.660000

Look at the load average - something is keeping the system very busy.  Could we find out which process(es) are the culprits?  If it's our process, attach the debugger and see what it's doing.  There should be an immense number of threads doing something.
Comment 11 Brendan Zagaeski (Xamarin Team, assistant) 2014-12-05 14:03:39 UTC
I believe 3 key factors involved in this problematic behavior are (roughly in order of importance):

1. The app currently uses a large (1.2 MB) background image.

2. The pixel density of the HTC One is high, so processing of each image in the scroll views might be comparatively CPU-intensive.

3. The horizontal scroll views are nested within a ListView.


From what I saw, none of these factors is specific to Xamarin. They all apply to Java Android apps on the HTC One as well. It might be appropriate to mark this bug RESOLVED UPSTREAM or RESOLVED INVALID.



## 1. Large background image

I was able to solve the problem in the original test case from comment 0 by either:

a. Resizing `background.png` from 768 x 1280 pixels down to 384 x 640 pixels before building the project.

or

b. Removing the `background.png` drawable resource from the project. The resource was used in `Main.axml`, `Fragment2Layout.axml`, and `splash_background.xml`.


I suspect this issue is closely related to bug 24508, comment 3. Note that this problem is not specific to Xamarin. I spent some time further simplifying the C# sample, and then I did a line-by-line port to Java. To my eye the performance of the Java sample is approximately identical to the C# sample: scrolling is "low frame rate" on an HTC One but fluid on an LG Optimus L9.



## 2. High pixel density on the HTC One

I created a second simplified C# sample to remove the UniversalImageLoader dependency. This also gave me easy access to the scaling ratio of the individual images. This second version of the app performs a bit worse than the original on an LG Optimus L9 because the image loading and caching are more simplistic, but the relative performance of the HTC One is still worse.

Decreasing the scale improves the scrolling speed on the HTC One. For example, if I scale all the images down to 20 x 20 pixels (the ImageViews on the HTC One are around 400 x 400 pixels), then the horizontal scroll views scroll smoothly.

Results in the line-by-line Java port were again equivalent.


### Optimus L9
Processor: dual-core 1 GHz
Pixel density: 234 ppi


### HTC One M7
Processor: quad-core 1.7 GHz
Pixel density: 469 ppi

Relative single-threaded processor speed: 1.7
Relative image size: 4
Relative (processor speed / image size): 0.4



## 3. Horizontal scroll views nested in ListView

Removing the "items" ListView from `Fragment2Layout.axml` and replacing it with 4 in-line copies of `Fragment2ListItem.axml` improves the scrolling behavior _some_. The effect is not as pronounced as downsampling the background image, but still noticeable.



## Version information

Xamarin.Android 4.20.0 (ba9bbbdd44cfdc4bf485e8885bd2ad24fba525f7)
java version "1.6.0_65"



## Steps to reproduce

1. Launch the test case (from comment 0).

2. Tap the drawer menu icon in the top left of the app and select "Nav 2".

3. Swipe the 3rd horizontal scroll view from right to left slowly to allow all of the images to download.

4. Swipe the scroll view back to the beginning.

5. Swipe the scroll view quickly from right to left. It's possible to move across the entire length of the scroll view in 1 swipe.



## Results

The scrolling speed is lower on an HTC One compared to an LG Optimus L9. More noticeably, the individual items in the scroll view do not "blur together" at all. For example, the thin black borders between items stay clearly visible and distinguishable for the duration of the scroll. There are never more than 4 borders visible at once. In contrast, on an Optimus L9 the items blur together more so that at times there appear to be more than 4 borders on the screen at once.

Downsampling the background image by a factor of 2 is sufficient to restore fluid scrolling on the HTC One so that more than 4 borders appear on the screen at once.
Comment 12 Brendan Zagaeski (Xamarin Team, assistant) 2016-11-18 03:56:52 UTC
## Status update

I am marking this old bug as resolved answered per the analysis in Comment 11 and in particular the finding that Java apps have the same behavior.
Comment 13 Brendan Zagaeski (Xamarin Team, assistant) 2016-11-18 03:57:20 UTC
*** Bug 46500 has been marked as a duplicate of this bug. ***