Xamarin은 Android에서 모노 구현과 C # 컴파일 된 앱이 Java 코드보다 빠르다고 주장했습니다. 다른 안드로이드 플랫폼에서 매우 유사한 Java 및 C # 코드에서 실제 벤치 마크를 수행하여 그러한 주장을 확인하고 코드와 결과를 게시 할 수 있습니까?

2013 년 6 월 18 일 추가됨

답이 없었으며 다른 사람들이 수행 한 벤치 마크를 찾을 수 없으므로 내 테스트를하기로 결정했습니다. 불행히도 내 질문은 "잠긴"상태로 유지되므로 답변으로 게시 할 수 없으며 질문 만 편집하십시오. 이 질문을 다시 열려면 투표하십시오. C #의 경우 Xamarin을 사용했습니다 .Android Ver. 4.7.09001 (베타). 소스 코드, 테스트 및 컴파일 된 APK 패키지에 사용 된 모든 데이터는 GitHub에 있습니다.

자바 : https://github.com/gregko/TtsSetup_Java

C # : https://github.com/gregko/TtsSetup_C_sharp

누군가 다른 장치 또는 에뮬레이터에서 테스트를 반복하고 싶다면 결과도 배우고 싶습니다.

내 테스트 결과

문장 추출기 클래스를 C # (@ Voice Aloud Reader 앱에서)으로 포팅하고 영어, 러시아어, 프랑스어, 폴란드어 및 체코 어로 10 개의 HTML 파일에서 테스트를 실행했습니다. 각 실행은 10 개의 파일 모두에서 5 번 수행되었으며 3 개의 서로 다른 장치와 하나의 에뮬레이터의 총 시간이 아래에 게시되어 있습니다. 디버깅을 사용하지 않고 "릴리스"빌드 만 테스트했습니다.

HTC Nexus One Android 2.3.7 (API 10)-CyanogenMod ROM

Java : 총 시간 (5 회) : 12361ms, 파일 읽기 총량 : 13304ms

C # : 총 시간 (5 회) : 17504ms, 파일 읽기 총량 : 17956ms

Samsung Galaxy S2 SGH-I777 (Android 4.0.4, API 15)-CyanogenMod ROM

Java : 총 시간 (5 회) : 8947ms, 파일 읽기 총계 : 9186ms

C # : 총 시간 (5 회) : 9884ms, 파일 읽기 총량 : 10247ms

Samsung GT-N7100 (Android 4.1.1 JellyBean, API 16)-Samsung ROM

Java : 총 시간 (5 회) : 9742ms, 파일 읽기 총계 : 10111ms

C # : 총 시간 (5 회) : 10459ms, 파일 읽기 총량 : 10696ms

에뮬레이터-인텔 (Android 4.2, API 17)

Java : 총 시간 (5 회) : 2699ms, 파일 읽기 총계 : 3127ms

C # : 총 시간 (5 회) : 2049ms, 파일 읽기 총량 : 2182ms

에뮬레이터-인텔 (Android 2.3.7, API 10)

Java : 총 시간 (5 회) : 2992ms, 파일 읽기 총계 : 3591ms

C # : 총 시간 (5 회) : 2049ms, 파일 읽기 총량 : 2257ms

에뮬레이터-Arm (Android 4.0.4, API 15)

Java : 총 시간 (5 회) : 41751ms, 파일 읽기 총계 : 43866ms

C # : 총 시간 (5 회) : 44136ms, 파일 읽기 총량 : 45109ms

간단한 토론

내 테스트 코드에는 주로 텍스트 파싱, 대체 및 Regex 검색이 포함되어 있으며 다른 코드 (예 : 더 많은 숫자 연산)의 경우 결과가 다를 수 있습니다. ARM 프로세서가 장착 된 모든 장치에서 Java는 Xamarin C # 코드보다 성능이 우수합니다. 가장 큰 차이점은 Android 2.3에서 C # 코드가 약 1에서 실행되는 것입니다. Java 속도의 70 %

Intel HAX 기술을 사용하는 Intel 에뮬레이터에서 에뮬레이터는 빠른 virt 모드로 실행됩니다. Xamarin C # 코드는 Java보다 훨씬 빠르게 샘플 코드를 약 1.35 배 빠르게 실행합니다. 아마도 모노 가상 머신 코드와 라이브러리가 ARM보다 인텔에서 훨씬 더 최적화되어 있습니까?

2013 년 7 월 8 일 수정

방금 Oracle VirtualBox에서 실행되는 Genymotion Android 에뮬레이터를 설치했으며 다시 ARM 프로세서를 에뮬레이션하지 않고 기본 Intel 프로세서를 사용합니다. Intel HAX 에뮬레이터와 마찬가지로 C #도 여기서 훨씬 더 빠르게 실행됩니다. 내 결과는 다음과 같습니다.

Genymotion 에뮬레이터-Intel (Android 4.1.1, API 16)

Java : 총 시간 (5 회) : 2069ms, 파일 읽기 총계 : 2248ms

C # : 총 시간 (5 회) : 1543ms, 파일 읽기 총계 : 1642ms

그런 다음 Xamarin.Android 베타 버전 4.7.11에 대한 업데이트가 모노 런타임의 일부 변경 사항을 언급하는 릴리스 노트와 함께 있음을 알았습니다. 일부 ARM 장치를 신속하게 테스트하기로 결정했으며 놀랍게도 C # 숫자가 향상되었습니다.

BN Nook XD +, ARM (Android 4.0)

Java : 총 시간 (5 회) : 8103ms, 파일 읽기 총량 : 8569ms

C # : 총 시간 (5 회) : 7951ms, 파일 읽기 총량 : 8161ms

와! C #이 이제 Java보다 낫습니까? Galaxy Note 2에서 테스트를 반복하기로 결정했습니다.

삼성 Galaxy Note 2-ARM (Android 4.1.1)

Java : 총 시간 (5 회) : 9675ms, 파일 읽기 총계 : 10028ms

C # : 총 시간 (5 회) : 9911ms, 파일 읽기 총계 : 10104ms

여기서 C #은 약간 느리게 보이지만이 숫자로 인해 잠시 멈추었습니다. Note 2의 프로세서 속도가 더 빠르더라도 Nook HD +보다 시간이 더 긴 이유는 무엇입니까? 답 : 절전 모드. Nook에서는 비활성화되었으며, 참고 2에서는 활성화되었습니다. 절전 모드를 비활성화 한 상태에서 테스트하기로 결정했습니다 (활성화 된 경우 프로세서 속도도 제한됨).

Samsung Galaxy Note 2-ARM (Android 4.1.1), 절전 기능 비활성화

Java : 총 시간 (5 회) : 7153ms, 파일 읽기 총량 : 7459ms

C # : 총 시간 (5 회) : 6906ms, 파일 읽기 총량 : 7070ms

놀랍게도 C #은 ARM 프로세서의 Java보다 약간 빠릅니다. 큰 개선!

2013 년 7 월 12 일 수정

우리 모두는 속도를 위해 네이티브 코드를 능가하는 것이 없으며 Java 또는 C #에서 문장 스플리터의 성능에 만족하지 못 했으므로 특히 개선해야합니다 (따라서 느리게 만들어야 함). C ++로 다시 작성하기로 결정했습니다. 다음은 절전 모드가 비활성화 된 상태에서 Galaxy Note 2의 기본 속도와 Java 속도를 비교 한 것입니다 (예 : 다른 이유로 이전 테스트보다 작은 파일 세트).

Java : 총 시간 (5 회) : 3292ms, 파일 읽기 총계 : 3454ms

기본 엄지 : 총 시간 (5 회) : 537ms, 파일 읽기 총 시간 : 657ms

네이티브 암 : 총 시간 (5 회) : 458ms, 파일 읽기 총계 : 587ms

내 특정 테스트의 경우 네이티브 코드가 Java보다 6 ~ 7 배 빠릅니다. 주의 사항 : Android에서 std :: regex 클래스를 사용할 수 없으므로 단락 나누기 또는 html 태그를 검색하는 고유 한 루틴을 작성해야했습니다. 정규식을 사용하는 PC에서 동일한 코드에 대한 초기 테스트는 Java보다 약 4-5 배 빠릅니다.

휴! char * 또는 wchar * 포인터를 사용하여 원시 메모리를 다시 깨우면 20 년이 더 젊어졌습니다. :)

2013 년 7 월 15 일 수정

Dot42로 훨씬 더 나은 결과를 얻으려면 2013 년 7 월 30 일의 수정 사항으로 아래를 참조하십시오.

약간의 어려움으로 C # 테스트를 Android의 또 다른 C # 플랫폼 인 Dot42 (버전 1.0.1.71 베타)로 이식 할 수있었습니다. 예비 결과에 따르면 Intel Android 에뮬레이터에서 Dot42 코드가 Xamarin C # (v. 4.7.11)보다 약 3 배 (3 배) 느립니다. 한 가지 문제는 Dot42의 System.Text.RegularExpressions 클래스에 Xamarin 테스트에서 사용한 Split () 함수가 없으므로 대신 Java.Util.Regex 클래스를 사용했으며 Java.Util.Regex.Pattern.Split () 코드의 특정 위치에는이 작은 차이가 있습니다. 그래도 큰 문제는 아닙니다. Dot42는 Dalvik (DEX) 코드로 컴파일되므로 기본적으로 Android에서 Java와 협력하며 Xamarin과 같이 C #에서 Java로 비싼 상호 운용성이 필요하지 않습니다.

비교를 위해 ARM 디바이스에서도 테스트를 실행합니다. 여기서 Dot42 코드는 Xamarin C #보다 "배속"만 2 배 느립니다. 내 결과는 다음과 같습니다.

HTC Nexus One Android 2.3.7 (ARM)

Java : 총 시간 (5 회) : 12187ms, 파일 읽기 총량 : 13200ms

Xamarin C # : 총계 총 시간 (5 회 실행) : 13935ms, 파일 읽기 총계 : 14465ms

Dot42 C # : 총 시간 (5 회) : 26000ms, 파일 읽기 총량 : 27168ms

삼성 Galaxy Note 2, Android 4.1.1 (ARM)

Java : 총 시간 (5 회) : 6895ms, 파일 읽기 총량 : 7275ms

Xamarin C # : 총 시간 (5 회) : 6466ms, 파일 읽기 총량 : 6720ms

Dot42 C # : 총 시간 (5 회) : 11185ms, 파일 읽기 총량 : 11843ms

인텔 에뮬레이터, Android 4.2 (x86)

Java : 총 시간 (5 회) : 2389ms, 파일 읽기 총계 : 2770ms

Xamarin C # : 총 시간 (5 회) : 1748ms, 파일 읽기 총량 : 1933ms

Dot42 C # : 총 시간 (5 회) : 5150ms, 파일 읽기 총량 : 5459ms

저에게는 Xamarin C #이 최신 ARM 장치에서 Java보다 약간 빠르며 이전 Nexus One에서는 약간 느리다는 점도 흥미로 웠습니다. 누구나이 테스트를 실행하려면 알려 주시면 GitHub에서 소스를 업데이트하겠습니다. Intel 프로세서가 장착 된 실제 Android 장치에서 결과를 보는 것이 특히 흥미로울 것입니다.

2013 년 7 월 26 일 업데이트

최신 Xamarin.Android 4.8 및 오늘 출시 된 dot42 1.0.1.72 업데이트로 벤치 마크 앱으로 다시 컴파일 된 빠른 업데이트만으로 이전에보고 된 결과와 큰 차이가 없습니다.

2013 년 7 월 30 일 업데이트-dot42에 대한 더 나은 결과

Java 코드의 Robert 's (dot42 제조업체에서) 포트를 사용하여 Dot42를 다시 테스트했습니다. Xamarin을 위해 처음 수행 된 C # 포트에서 ListArray와 같은 일부 고유 Java 클래스를 C # 고유의 List 클래스로 대체했습니다. Robert는 Dot42 소스 코드를 가지고 있지 않으므로 Java에서 다시 포팅하여 원래 Java 클래스를 사용했습니다. Dot42에 도움이되는 그러한 장소는 Xamarin과 같이 Mono가 아닌 Java와 같은 Dalvik VM에서 실행되기 때문에 추측합니다. 이제 Dot42 결과가 훨씬 좋습니다. 내 테스트의 로그는 다음과 같습니다.

2013 년 7 월 30 일-Dot42 C #에서 더 많은 Java 클래스로 Dot42 테스트

인텔 에뮬레이터, 안드로이드 4.2

Dot42, StringBuilder.Replace ()를 사용하는 Greg의 코드 (Xamarin에서와 같이) :
총 시간 (5 회 실행) : 3646ms, 파일 읽기 총계 : 3830ms

Dot42, String.Replace ()를 사용하는 Greg의 코드 (Java 및 Robert의 코드에서와 같이) :
총 시간 (5 회 실행) : 3027ms, 파일 읽기 총계 : 3206ms

Dot42, Robert의 코드 :
총 시간 (5 회) : 1781ms, 파일 읽기 총 시간 : 1999ms

Xamarin :
총 시간 (5 회) : 1373ms , 파일 읽기 총 시간 : 1505ms

Java :
총 시간 (5 회) : 1841ms, 파일 읽기 총계 : 2044ms

ARM, Samsung Galaxy Note 2, 절전, Android 4.1.1

Dot42, StringBuilder.Replace ()를 사용하는 Greg의 코드 (Xamarin에서와 같이) :
총 시간 (5 회 실행) : 10875ms, 파일 읽기 총계 : 11280ms

Dot42, String.Replace ()를 사용하는 Greg의 코드 (Java 및 Robert의 코드에서와 같이) :
총 시간 (5 회 실행) : 9710ms, 파일 읽기 총계 : 10097ms

Dot42, Robert 's Code :
총 시간 (5 회) : 6279ms, 파일 읽기 총량 : 6622ms

Xamarin :
총 시간 (5 회) : 6201ms , 파일 읽기 총량 : 6476ms

Java :
총 시간 (5 회) : 7141ms, 파일 읽기 총량 : 7479ms

나는 아직도 Dot42가 갈 길이 멀다고 생각한다. Java와 같은 클래스 (예 : ArrayList)가 있고 성능이 좋으면 Java에서 C #으로 코드를 포팅하는 것이 약간 쉬워집니다. 그러나 이것은 내가 많이하지 않을 것입니다. 오히려 네이티브 C # 클래스 (예 : List)를 사용하는 기존 C # 코드 (라이브러리 등)를 사용하고 싶습니다. 이는 현재 dot42 코드에서 느리게 수행되며 Xamarin에서는 매우 잘 수행됩니다.

그렉

예, Xamarin의 모노 가상 머신은 Android에서 사용되는 Google의 Dalvik보다 더 인상적입니다. HTC Flyer 및 Acer Iconia Tab 태블릿을 사용하여 Java Dalvik에 대해 Mono를 통해 Android의 C # 포트를 벤치마킹하고 Android를 C #으로 구현하고 실제로 Java 기반 Dalvik을 우회하는 벤치 마크로 테스트했습니다.

I came across this interesting post

https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.kfbauchtz

이 정보가 도움이 되길 바랍니다.

최근에 앱에 Xamarin을 사용하여 조사했습니다. 우리는 Windows RT 버전의 앱을 위해 이미 작성한 C # 코드를 활용했습니다. Android 버전에 대한 일부 세부 정보를 다시 작성해야했습니다.

우리가 발견 한 것은 Xamarin C #의 I / O가 Java보다 약 2 배 느리다는 것입니다. 우리의 응용 프로그램은 I / O가 많이 제한됩니다. 우리는 아직 이것의 원인을 발견하지 못했지만 현재 마샬링으로 인한 것이라고 가정하고 있습니다. 우리는 대부분 Mono VM 내부에 머 무르려고 노력하지만 Mono가 실제로 디스크에 액세스하는 방법을 모릅니다.

또한 C # 코드는 SQLite.NET ( https://github.com/praeclarum/sqlite-net )을 사용한다고 알려줍니다 . SQLite.NET 코드를 사용하는 동일한 반입도 Android의 Java SQLite 랩퍼를 사용하는 것보다 2 배 느립니다. 소스 코드를 살펴본 후 C .dll에 직접 바인딩되는 것처럼 보이므로 너무 느린 이유를 모르겠습니다. 한 가지 가능성은 네이티브에서 Java로 문자열을 마샬링하는 것이 C #에서 네이티브보다 Xamarin보다 안드로이드에서 더 빠를 수 있습니다.

이것은 내가 당신과 공유하고 싶은 또 다른 업데이트 된 블로그 게시물 입니다. 그는 Xamarin과 IO 및 Android의 네이티브 코드 및 Cordova를 비교합니다.

간단히 말해서, Xamarin은 때로는 원시 코드보다 성능이 우수합니다. 그는 앱 크기,로드 시간, Azure 서비스 및 소수 계산에서 목록로드를 테스트했습니다.

즐겨!

편집 : 죽은 링크를 업데이트하고 2 부가 있음을 알았습니다.

다음은 두 가지 장치에서 네이티브, Xamarin 및 Xamarin 사이의 다른 테스트에서 찾은 몇 가지 정보입니다.

Samsung Galaxy A7 : Android OS 버전 : 6.0 중앙 처리 장치 : Octa-core 1.9 GHz Cortex-A53 RAM : 3GB 디스플레이 해상도 : 1920 × 1080

iPhone 6s : iOS 버전 : 10.3.3 중앙 처리 장치 : 듀얼 코어 1.84 GHz 트위스터 RAM : 2 GB 디스플레이 해상도 : 1334 × 750

비교는 몇 가지 일반적인 기능에 대해 이루어지며 각각 고유 한 응용 프로그램이 있습니다.

- Basic “Hello World”
- REST API
- JSON Serialization/Deserialization
- Photo Loading
- SQL Database Insert and Get All

각 테스트는 여러 번 반복되며 그래프는 평균 결과를 보여줍니다.

안녕하세요 월드

나머지 API

OpenWeatherMap API를 사용하여 앱이 REST API를 통해 요청을 보내고 추가 데이터 처리없이 응답을 다시받는 데 걸리는 시간을 측정하기위한 테스트 세트입니다.

JSON 작업 테스트는 Newtonsoft Json.net 프레임 워크를 사용하여 모든 Xamarin 앱에서 JSON 객체를 직렬화하고 직렬화 해제합니다. 기본 Android 직렬화 및 역 직렬화는 Jackson과 GSON의 두 Java 라이브러리를 사용하여 테스트되었습니다.

처음에는 처음부터 두 번, 캐시 된 정보 및 작업이있는 두 번은 두 번 실행됩니다.

첫 실행 :

(Native iOS JSON Operations는이 테스트를 중단하고 Xamarin은 두 번째 테스트에 참여합니다)

사진 작업

먼저 세 가지 해상도로 이미지를로드하십시오.

Resolution – 858×569, Size – 868Kb
Resolution – 2575×1709, Size – 8Mb
Resolution – 4291×2848, Size – 28.9Mb

이 테스트의 Xamarin.Forms 결과에 대해 확실하지 않은 것 같으므로 그래프에 포함되지 않았습니다.

SQLite 작업

테스트 된 두 가지 작업 :

BulkInsert: Loading rows of data into a database table.
GetAll: Retrieving all data from the database.

10,000 개의 레코드가있는 데이터베이스 모든 작업은 장치에서 내부적으로 처리되었습니다.

Xamarin Native (Xamarin.iOS / Xamarin.Android)는 네이티브 코드에 대한 대체 대안으로 적합하지만 Xamarin.Forms는 많은 경우에 느리게 보이지만 실제로는 간단한 응용 프로그램을 신속하게 개발하는 정말 좋은 솔루션이 될 수 있습니다.

이 소스에서 완전한 테스트를 수행합니다.

https://www.altexsoft.com/blog/engineering/performance-comparison-xamarin-forms-xamarin-ios-xamarin-android-vs-android-and-ios-native-applications/

내 답변을 향상시키기 위해 설명을 해 주셔서 감사합니다. 이것이 약간 도움이되기를 바랍니다.)

공연

성능이 의미하는 바를 정의하지 않으면 성능이 모호합니다. 일반 계산 성능 인 경우 Xamarin은 계산의 특성에 따라 Java보다 빠를 수 있습니다.

안드로이드는 코드를 실행하기 위해 여러 형태로 제공됩니다

• 렌더 스크립트 (CPU 및 GPU)
• 자바 (SDK)
• C ++ (NDK)
• OpenGL (GPU)

코드를 실행할 때 솔루션이 더 기본 솔루션 일수록 더 빠를 것입니다. 런타임 기반 언어는 CPU에서 직접 실행되는 언어를 절대 능가하지 않습니다.

그러나 실제 사용 성능을 측정하려면 Java가 Xamarin보다 빠를 것입니다.

Xamarin과 왜 느려질 수 있습니까?

Xamarin을 일반 오래된 Java 응용 프로그램과 비교하면 Xamarin의 성능이 느려질 수 있으므로 성능이 훨씬 빨라질 수 있습니다.

실제 예에서 Xamarin 애플리케이션은 많은 Android / Java (시스템) 호출을 소위 바인딩을 사용하여 Xamarin 런타임으로 위임해야하고 Java 애플리케이션보다 느릴 가능성이 높습니다.

알아야 할 몇 가지 다른 유형의 바인딩이 있습니다.

• JNI (Java Native Interface) : 많은 Android 애플리케이션에서 Java 코드 (SDK)와 네이티브 C ++ 코드 (NDK) 사이의 인터페이스를 위해 사용되는 바인딩입니다.
• MCW (Managed Callable Wrappers) : Xamarin에서 관리되는 C # 코드에서 Java 코드 (Android 런타임)로 인터페이스하기 위해 사용할 수있는 바인딩입니다.
• ACW (Android Callable Wrappers) : Xamarin에서 Java 코드 (Android 런타임)에서 관리되는 C # 코드로 인터페이스하기 위해 사용할 수있는 바인딩입니다.

MCW 및 ACW에 대한 자세한 내용은 https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform/

바인딩은 성능면에서 매우 비용이 많이 듭니다. Java에서 C ++ 메소드를 호출하면 호출 시간에 막대한 오버 헤드가 추가되고 C ++에서 C ++ 메소드를 호출하는 것이 여러 번 더 빠릅니다.

누군가 JNI 호출 비용의 평균 Java 작업 수를 계산하기 위해 성능 테스트를 수행했습니다. JNI 호출 의 양적 오버 헤드는 무엇입니까?

그러나 JNI 통화뿐만 아니라 MCW 및 ACW와의 통화도 비용이 많이 듭니다. 실제 Xamarin 애플리케이션은 바인딩을 사용하여 많은 호출을 수행하며 Xamarin 애플리케이션의 실제 사용으로 인해 일반 Java 애플리케이션보다 느릴 수 있습니다 (일반적으로). 그러나 Xamarin 애플리케이션의 설계 방식에 따라 사용자는 차이를 느끼지 못할 가능성이 큽니다.

TLDR / 결론 : Xamarin은 시간이 많이 걸리는 als 종류 바인딩을 사용해야합니다.

바인딩 외에도 실제 성능에 관해 이야기 할 때 바이너리의 크기, 메모리에 앱로드, I / O 작업 등과 같은 다른 많은 요소가 있습니다. 이러한 것들 중 일부를 조사하는 블로그 게시물은 https://magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin-forms 에서 찾을 수 있습니다.

꽤 오래된 테스트이지만 관련이있을 수 있습니다 : https://github.com/EgorBo/Xamarin.Android-vs-Java

산술 테스트

컬렉션, 제네릭, 맞춤 값 유형

문자열 다루기

UPD : Google Pixel 2의 새로운 데이터 ( Yousha-Aleayoub 덕분에 )