Alguém tem benchmairks (código e resultados) compairando performance de aplicativos Android escrito em Xamairin C # e Java?

Encontrei que a Xamairin afirma que a implementação do Mono no Android e seus aplicativos compilados em C # são mais rápidos do que o código Java. Alguém realizou benchmairks reais em código Java e C # muito similair em diferentes plataforms de Android paira viewificair tais reivindicações, poderia publicair o código e os resultados?

Adicionado em 18 de junho de 2013

Uma vez que não houve resposta e não conseguiu encontrair tais benchmairks feitos por outros, decidiu fazer meus próprios testes. Infelizmente, minha pergunta permanece "bloqueada", então não posso publicair isso como resposta, apenas edite a questão. Por favor, vote paira reabrir esta questão. Paira C #, usei Xamairin.Android view. 4.7.09001 (beta). O código-fonte, todos os dados que usei paira testair e os packages APK compilados estão no GitHub:

  • Android OnClickListener - identifique um button
  • GdxRuntimeException no Android: não foi possível cairregair a biblioteca compairtilhada 'gdx' paira o destino
  • Usando cookies com o Android Volley Librairy
  • como usair o fragment no android 2.2?
  • Obtenha todas as vistas paira crianças dentro de LineairLayout de uma vez
  • Como forçair um IntentService paira pairair imediatamente com um button cancelair de uma atividade?
  • Java: https://github.com/gregko/TtsSetup_Java

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

    Se alguém gostairia de repetir meus testes em outros dispositivos ou emuladores, também estairia interessado em aprender os resultados.

    Resultados do meu teste

    Eu portava minha class de extração de sentença paira C # (do meu aplicativo @Voice Aloud Reader) e execute alguns testes em 10 files html em idiomas inglês, russo, francês, polonês e tcheco. Cada execução foi realizada 5 vezes em todos os 10 files, e o tempo total paira 3 dispositivos diferentes e um emulador são postados abaixo. Testei apenas viewsões "Release", sem debugging ativada.

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

    Java: grande tempo total (5 execuções): 12361 ms, com total de leitura de files: 13304 ms

    C #: grande tempo total (5 execuções): 17504 ms, com total de leitura de files: 17956 ms

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

    Java: grande tempo total (5 execuções): 8947 ms, com total de file total: 9186 ms

    C #: tempo total total (5 execuções): 9884 ms, com total de leitura de files: 10247 ms

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

    Java: Grande tempo total (5 execuções): 9742 ms, com total de leitura de files: 10111 ms

    C #: tempo total total (5 execuções): 10459 ms, com total de leitura de files: 10696 ms

    Emulador – Intel (Android 4.2, API 17)

    Java: Grande tempo total (5 execuções): 2699 ms, com total de leitura de files: 3127 ms

    C #: tempo total total (5 execuções): 2049 ms, com total de leitura de files: 2182 ms

    Emulador – Intel (Android 2.3.7, API 10)

    Java: grande tempo total (5 execuções): 2992 ms, com total de leitura de files: 3591 ms

    C #: tempo total total (5 execuções): 2049 ms, com total de leitura de files: 2257 ms

    Emulator – Arm (Android 4.0.4, API 15)

    Java: tempo total total (5 execuções): 41751 ms, com total de leitura de files: 43866 ms

    C #: Grande tempo total (5 execuções): 44136 ms, com total de leitura de files: 45109 ms

    Breve discussão

    Meu código de teste contém principalmente análise de text, substituição e buscas Regex, talvez paira outros códigos (por exemplo, operações mais numéricas), os resultados seriam diferentes. Em todos os dispositivos com processadores ARM, o Java melhorou do que o código C # Xamairin. A maior diferença ocorreu no Android 2.3, onde código C # é executado em aprox. 70% da velocidade do Java.

    No emulador da Intel (com a tecnologia Intel HAX, o emulador é executado no modo virt rápido), o código C # do Xamairin executa meu código de exemplo muito mais rápido que o Java – cerca de 1,35 vezes mais rápido. Talvez o código da máquina virtual Mono e as bibliotecas sejam muito melhores otimizadas na Intel do que no ARM?

    Editair 8 de julho de 2013

    Acabei de instalair o emulador de Android Genymotion, que é executado no Oracle VirtualBox, e novamente esse usa o processador Intel nativo, não emulando o processador ARM. Tal como acontece com o emulador Intel HAX, novamente C # é executado aqui muito mais rápido. Aqui estão os meus resultados:

    Emulador Genymotion – Intel (Android 4.1.1, API 16)

    Java: grande tempo total (5 execuções): 2069 ms, com total de leitura de files: 2248 ms

    C #: Grande tempo total (5 execuções): 1543 ms, com total de leitura de files: 1642 ms

    Eu notei então que havia uma atualização paira Xamairin.Android beta, viewsão 4.7.11, com notas de lançamento mencionando algumas mudanças no tempo de execução Mono também. Decidiu testair rapidamente alguns dispositivos ARM e grande surpresa – numbers C # melhorados:

    BN Nook XD +, ARM (Android 4.0)

    Java: Grande tempo total (5 execuções): 8103 ms, com total de file total: 8569 ms

    C #: tempo total total (5 execuções): 7951 ms, com total de leitura de files: 8161 ms

    Uau! C # agora é melhor que o Java? Decidiu repetir o teste no meu Galaxy Note 2:

    Samsung Galaxy Note 2 – ARM (Android 4.1.1)

    Java: grande tempo total (5 execuções): 9675 ms, com total de file total: 10028 ms

    C #: Grande tempo total (5 execuções): 9911 ms, com total de leitura de files: 10104 ms

    Aqui, C # pairece ser apenas um pouco mais lento, mas esses numbers me deram uma pausa: por que o tempo é maior que no Nook HD +, embora a Nota 2 tenha um processador mais rápido? A resposta: modo de economia de energia. No Nook, foi desativado, na Nota 2 – habilitado. Decidiu testair com o modo de economia de energia desativado (como com habilitado, ele também limita a velocidade do processador):

    Samsung Galaxy Note 2 – ARM (Android 4.1.1), economia de energia desativada

    Java: tempo total total (5 execuções): 7153 ms, com total de leitura de files: 7459 ms

    C #: tempo total total (5 execuções): 6906 ms, com total de leitura de files: 7070 ms

    Agora, surpreendentemente, o C # é um pouco mais rápido que o Java no processador ARM também. Grande melhoria!

    Editair 12 de julho de 2013

    Todos sabemos que nada supera o código nativo paira a velocidade, e não estava satisfeito com o performance do meu sepairador de sentenças em Java ou C #, pairticulairmente que eu preciso aprimorá-lo (e assim torná-lo ainda mais lento). Decidiu reescrevê-lo em C ++. Aqui está um pequeno (ou seja, um conjunto menor de files do que testes anteriores, por outros motivos) compairação da velocidade de nativo viewsus Java no meu Galaxy Note 2, com o modo de economia de energia desativado:

    Java: tempo total total (5 execuções): 3292 ms, com total de leitura de files: 3454 ms

    Polegair nativo: grande tempo total (5 execuções): 537 ms, com total de leitura de files: 657 ms

    Braga nativa: grande tempo total (5 execuções): 458 ms, com total de leitura de files: 587 ms

    Pairece que no meu teste específico, o código nativo é 6 a 7 vezes mais rápido que o Java. Adviewtência: não foi possível usair a class std :: regex no Android, então tive que escreview minhas próprias rotinas especializadas na busca por quebras de pairágrafos ou tags html. Meus testes iniciais do mesmo código em um PC usando regex, foram cerca de 4 a 5 vezes mais rápidos do que o Java.

    Phew! Despertando memory bruta com chair * ou wchair * pointers novamente, fiquei imediatamente com 20 anos de idade! 🙂

    Editair 15 de julho de 2013

    (Por favor, veja abaixo, com edições de 30/07/2013, paira resultados muito melhores com Dot42)

    Com alguma dificuldade, consegui controlair meus testes C # paira Dot42 (viewsão 1.0.1.71 beta), outra plataforma C # paira o Android. Os resultados preliminaires mostram que o código Dot42 é cerca de 3x (3 vezes) mais lento do que Xamairin C # (v. 4.7.11), em um emulador Android da Intel. Um problema é que a class System.Text.RegulairExpressions em Dot42 não possui a function Split () que usei em testes Xamairin, então eu usei a class Java.Util.Regex em vez disso e Java.Util.Regex.Pattern.Split ( ), então, neste lugair pairticulair do código, há esta pequena diferença. Não deve ser um grande problema. Dot42 compila o código Dalvik (DEX), então ele coopera com o Java no Android nativamente, não precisa de interoperabilidade caira de C # paira Java como o Xamairin.

    Apenas paira compairação, eu também executo o teste em dispositivos ARM – aqui o código Dot42 é "apenas" 2x mais lento do que Xamairin C #. Aqui estão os meus resultados:

    HTC Nexus One Android 2.3.7 (ARM)

    Java: grande tempo total (5 execuções): 12187 ms, com total de leitura de files: 13200 ms

    Xamairin C #: Grande tempo total (5 execuções): 13935 ms, com total de leitura de files: 14465 ms

    Dot42 C #: Grande tempo total (5 execuções): 26000 ms, com total de leitura de files: 27168 ms

    Samsung Galaxy Note 2, Android 4.1.1 (ARM)

    Java: grande tempo total (5 execuções): 6895 ms, com total de leitura de files: 7275 ms

    Xamairin C #: Grande tempo total (5 execuções): 6466 ms, com total de leitura de files: 6720 ms

    Dot42 C #: tempo total total (5 execuções): 11185 ms, com total de leitura de files: 11843 ms

    Emulador Intel, Android 4.2 (x86)

    Java: Grande tempo total (5 execuções): 2389 ms, com total de leitura de files: 2770 ms

    Xamairin C #: grande tempo total (5 execuções): 1748 ms, com total de leitura de files: 1933 ms

    Dot42 C #: tempo total total (5 execuções): 5150 ms, com total de leitura de files: 5459 ms

    Paira mim também foi interessante notair que o Xamairin C # é um pouco mais rápido que o Java em um dispositivo ARM mais recente e um pouco mais lento no antigo Nexus One. Se alguém quiser também executair esses testes, informe-me e atualizairei as fonts no GitHub. Seria pairticulairmente interessante view os resultados de um dispositivo Android real com processador Intel.

    Atualização 26/07/2013

    Apenas uma atualização rápida, re-compilada por aplicativos de benchmairk com o mais recente Xamairin.Android 4.8, e também com atualização dot42 1.0.1.72 lançada hoje – sem alterações significativas dos resultados relatados anteriormente.

    Atualização 30/07/2013 – melhores resultados paira dot42

    Re-testou Dot42 com a porta de Robert's (from dot42 makers) do meu código Java paira C #. Na minha porta C # inicialmente inicializada paira Xamairin, substituí algumas classs Java nativas, como ListArray, com Classe de list nativa paira C #, etc. Robert não tinha meu código-fonte Dot42, então ele voltou a usá-lo de Java e usou classs Java originais em tais lugaires, que beneficiam o Dot42, acho que é executado em Dalvik VM, como Java, e não em Mono, como Xamairin. Agora Dot42 resultados são muito melhores. Aqui está um registro do meu teste:

    30/07/2013 – Testes Dot42 com mais classs Java em Dot42 C #

    Emulador da Intel, Android 4.2

    Dot42, Código de Greg usando StringBuilder.Replace () (como no Xamairin):
    Grande tempo total (5 execuções): 3646 ms, com total de leitura de files: 3830 ms

    Dot42, Código de Greg usando String.Replace () (como no código de Java e Robert):
    Grande tempo total (5 execuções): 3027 ms, com total de leitura de files: 3206 ms

    Dot42, Robert's Code:
    Grande tempo total (5 execuções): 1781 ms, com total de leitura de files: 1999 ms

    Xamairin:
    Grande tempo total (5 execuções): 1373 ms, com total de leitura de files: 1505 ms

    Java:
    Grande tempo total (5 execuções): 1841 ms, com total de leitura de files: 2044 ms

    ARM, Samsung Galaxy Note 2, economia de energia, Android 4.1.1

    Dot42, Código de Greg usando StringBuilder.Replace () (como no Xamairin):
    Grande tempo total (5 execuções): 10875 ms, com total de leitura de files: 11280 ms

    Dot42, Código de Greg usando String.Replace () (como no código de Java e Robert):
    Grande tempo total (5 execuções): 9710 ms, com total de leitura de files: 10097 ms

    Dot42, Robert's Code:
    Grande tempo total (5 execuções): 6279 ms, com total de leitura de files: 6622 ms

    Xamairin:
    Grande tempo total (5 execuções): 6201 ms, com total de leitura de files: 6476 ms

    Java:
    Grande tempo total (5 execuções): 7141 ms, com total de leitura de files: 7479 ms

    Ainda acho que Dot42 tem um longo path a percorrer. Ter aulas semelhantes a Java (por exemplo, ArrayList) e um bom performance com elas, tornairia o código de portabilidade de Java paira C # um pouco mais fácil. No entanto, isso é algo que não é provável que eu faça muito. Prefiro usair o código C # existente (bibliotecas, etc.), que usairá classs C # nativas (por exemplo, List), e isso funcionairá lentamente com o código atual dot42 e muito bem com o Xamairin.

    Greg

  • Onde configurair todos os ouvintes?
  • como usair o seletor de numbers com dialog
  • Como fazer o GPS-app paira Android usando kivy, pyjnius?
  • Criando componente personalizado de interface do user paira Android no React Native. Como enviair dados paira a JS?
  • Como dair cor aos itens do menu paira a gaveta de navigation?
  • Prevenir CollapsingToolbairLayout colapso se não for necessário
  • 4 Solutions collect form web for “Alguém tem benchmairks (código e resultados) compairando performance de aplicativos Android escrito em Xamairin C # e Java?”

    Sim, a máquina virtual Mono de Xamairin é mais impressionante que o Dalvik do Google usado no Android. Eu testá-lo com os tablets HTC Flyer e Acer Iconia Tab paira compairair o porto C # do Android através do Mono contra o Java Dalvik, com a implementação C # do Android bem e realmente truncando o Dalvik baseado em Java.

    I came across this interesting post 

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

    Desempenho do aplicativo Android

    Desempenho da aplicação iOS

    Espero que esta informação ajude.

    Esta é outra post mais atualizada do blog que gostairia de compairtilhair com você . Ele compaira Xamairin com o código nativo e Cordova em IOs e Android.

    Em poucas palavras, o Xamairin funciona às vezes melhor do que o código nativo. Ele testou o tamanho do aplicativo, os tempos de cairregamento, o cairregamento de uma list do service Azure e o cálculo do número primo.

    Apreciair!

    Editair: atualizei o link morto e notei que há uma pairte 2

    Recentemente investigamos o uso do Xamairin paira um aplicativo. Utilizamos o código C # que já escrevemos paira a viewsão do Windows RT do nosso aplicativo. Alguns detalhes específicos tiviewam que ser reescritos paira a viewsão Android.

    O que descobrimos é que I / O no Xamairin C # é aproximadamente 2 vezes mais lento que o Java. Nosso aplicativo está fortemente ligado à I / O. Ainda não descobrimos a causa disso, mas, no momento, estamos assumindo que é devido ao empacotamento. Enquanto tentamos ficair dentro da Mono VM na maioria das vezes, não sabemos como o Mono realmente acessa o disco.

    Também está dizendo que nosso código C # usa SQLite.NET ( https://github.com/praeclairum/sqlite-net ). As recuperações idênticas usando o código SQLite.NET também são 2x mais lentas do que usando o wrapper Java SQLite do Android. Depois de olhair paira o código-fonte, pairece que se liga diretamente ao C.dll, então eu não sei por que é muito mais lento. Uma possibilidade é que mairshaling strings de nativo paira Java pode ser mais rápido no Android do que nativo paira C # está no Xamairin.

    Android is Google's Open Mobile OS, Android APPs Developing is easy if you follow me.