Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Touchpad im Test: iPad-Klon von HP…

Träge trotz mehr PS

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Träge trotz mehr PS

    Autor: scrumm3r 13.07.11 - 12:58

    Das deckt sich mit meinen eigenen Erfahrungen. Apple macht alles richtig, wenn sie Programmierer dazu zwingen mit hardwarenahen Programmiersprachen wie C, C++ und Objective-C zu programmieren. Trotz deutlich weniger RAM und CPU-Power ziehen die iGeräte hoffnungslos übervorteilt an der Konkurrenz vorbei.

    Java und JavaScript sind die 2 Stricke, mit denen Android und WebOS sich die Beine zusammenbinden.

  2. Re: Träge trotz mehr PS

    Autor: Junior-Consultant 13.07.11 - 13:36

    Apple zwingt niemanden.

    Man kann für das iPhone auch sehr gut native Apps in Javascript, HTML5 und CSS3 schreiben.

    Siehe:
    http://www.phonegap.com/apps

  3. Leider falsch

    Autor: scrumm3r 13.07.11 - 13:39

    Da liegst du leider falsch. iApps auf Basis von Titanium oder PhoneGap sind allesamt ganz schlechte Beispiele für gute Bedienbarkeit. Sie sind all das, was man von WebOS und Android nur zu geht kennt und hasst: träge und hemmungslose Batteriesauger.



    1 mal bearbeitet, zuletzt am 13.07.11 13:40 durch scrumm3r.

  4. Re: Träge trotz mehr PS

    Autor: Wahrheitssager 13.07.11 - 13:43

    JavaScript muss nicht unbedingt langsamer sein.

  5. Re: Träge trotz mehr PS

    Autor: AndyGER 13.07.11 - 14:15

    Weil? Mir fehlt da irgendwo jetzt die Begründung und das Beispiel ... :)

    ===============================================================
    Its Time to think. More Different ...

  6. Re: Leider falsch

    Autor: Yeeeeeeeeha 13.07.11 - 14:56

    Ich programmiere gerade eine App mit Phonegap und Sencha Touch (Portierung eines Programms, das normalerweise in einem Java mit Webkit-Window läuft). Nebenbei portiere ich die GUI testweise in eine native GUI, also reines Objective-C mit dem GUIKit von iOS,

    Es ist ein Unterschied wie Tag und Nacht. Zwar Ist die Bedienung an sich fast identisch (Sencha Touch baut das GUIKit quasi nach), die Performance ist aber verglichen unterirdisch.
    Der große Unterschied ist halt, dass native GUIs in iOS komplett GPU-beschleunigt sind.

    Yeeeeeeeeha - Nur echt mit 2^3 e
    Perl-Monk, Java-Trinker, Objective-C Wizard, PHP-Kiddie, unfreiwilliger FreeBSD-/Linux-Teilzeitadmin

  7. Re: Träge trotz mehr PS

    Autor: gorsch 13.07.11 - 15:36

    >Der große Unterschied ist halt, dass native GUIs in iOS komplett GPU-beschleunigt sind.
    Das ist eben genau der Punkt. Solange die drawing Routinen fein vom Applikationsthread entkoppelt sind und auf die Hardware zurückgreifen kann man ohne weiteres auch in Java oder Javascript völlig flüssige Anwendungen entwickeln. (Die Anwendungslogik ist ja bei den meisten Apps auch wenig aufwendig)
    Das Problem ist aber, dass z.B. Android das ganze System oftmals auf die Garbage Collection warten muss und dann stockt es eben.
    Und inwiefern man jetzt Objective-C als hardwarenah bezeichnen kann, sei mal dahingestellt, aber reiner Objective-C code ist wohl kaum schneller als Javascript auf modernen JIT engine.

  8. Re: Träge trotz mehr PS

    Autor: Yeeeeeeeeha 13.07.11 - 16:14

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > Das ist eben genau der Punkt. Solange die drawing Routinen fein vom
    > Applikationsthread entkoppelt sind und auf die Hardware zurückgreifen kann
    > man ohne weiteres auch in Java oder Javascript völlig flüssige Anwendungen
    > entwickeln. (Die Anwendungslogik ist ja bei den meisten Apps auch wenig
    > aufwendig)

    Jup. In iOS läuft zwar das Aktualisieren der GUI im Hauptthread, so etwas wie Animationen oder Scrollen aber eben nebenläufig.

    > Das Problem ist aber, dass z.B. Android das ganze System oftmals auf die
    > Garbage Collection warten muss und dann stockt es eben.

    Richtig. Deshalb läuft es ja auch den Tablets mit DualCore-ARM auch deutlich durchgängiger flüssig (zudem bei Honeycomb zumindest teilweise die GPU benutzt wird).

    > Und inwiefern man jetzt Objective-C als hardwarenah bezeichnen kann, sei
    > mal dahingestellt, aber reiner Objective-C code ist wohl kaum schneller als
    > Javascript auf modernen JIT engine.

    Hmmm naja, JIT Engines sind schon sehr schnell, trotzdem gibt es noch immer einen recht großen Unterschied.
    Objective-C ist eigentlich nichts anderes als eine Erweiterung von C (man kann auch stinknormales C reinprogrammieren, benutze ich z.B. für SQLite und JSON-Libs) und wird dementsprechend optimiert compiliert. Wirklich hardwarenah ist es nicht, da man in der Regel sehr viel die Libs wie das GUIKit benutzt. Allerdings gibt es einen gewaltigen Unterschied zu Javascript: Die dynamische Typisierung. Dabei fällt eine Menge Konvertierungsfoo weg, was - je nach App - durchaus einen größeren Unterschied machen kann.

    Yeeeeeeeeha - Nur echt mit 2^3 e
    Perl-Monk, Java-Trinker, Objective-C Wizard, PHP-Kiddie, unfreiwilliger FreeBSD-/Linux-Teilzeitadmin

  9. Re: Leider falsch

    Autor: scrumm3r 13.07.11 - 17:17

    Dann haben wir ja was gemeinsam. Ich benutze Titanium nurnoch für Prototypen und halte es für eine Sünde am Kunden, ihm sowas aufzuschwatzen ...

  10. Re: Träge trotz mehr PS

    Autor: scrumm3r 13.07.11 - 17:21

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > ... aber reiner Objective-C code ist wohl kaum schneller als
    > Javascript auf modernen JIT engine.

    Und das weißt du weshalb so genau?

    Das die Wahrheit komplett anders aussieht, merke ich jeden Tag bei der Arbeit ...

  11. Re: Träge trotz mehr PS

    Autor: Junior-Consultant 13.07.11 - 17:36

    "Da liegst du leider falsch. iApps auf Basis von Titanium oder PhoneGap sind allesamt ganz schlechte Beispiele für gute Bedienbarkeit. Sie sind all das, was man von WebOS und Android nur zu geht kennt und hasst: träge und hemmungslose Batteriesauger."

    Kompletter Unsinn. Ich habe bereits Apps auf Basis von Objective C, Sencha Touch und JQTouch / PhoneGap entwickelt und bei richtiger Herangehensweise stimmt das einfach überhaupt nicht. Gerade bei den GPU-beschleunigten CSS3 Transitions sehe ich keinen Unterschied mehr zur nativen Anwendung.



    1 mal bearbeitet, zuletzt am 13.07.11 17:38 durch Junior-Consultant.

  12. Re: Träge trotz mehr PS

    Autor: .ldap 13.07.11 - 17:47

    Core Graphics ist zum Beispiel 100% C#/C++. Einfach, weil die Animationen dann viel schneller dargestellt werden können.

  13. Re: Träge trotz mehr PS

    Autor: scrumm3r 13.07.11 - 20:46

    Dann hast du leider noch nichts geschrieben, dass über einen gewissen Grad an Komplexität hinausgeht.

  14. Re: Träge trotz mehr PS

    Autor: scrumm3r 13.07.11 - 20:49

    CopreGraphics ist nicht in C# geschrieben. Es besteht hauptsächlich aus reinem C, OpenCL und beinhaltet ein paar Spuren von C++. Wie kommst du dazu, solche Behauptungen aufzustellen?

  15. Re: Träge trotz mehr PS

    Autor: Schnarchnase 13.07.11 - 21:29

    scrumm3r schrieb:
    --------------------------------------------------------------------------------
    > Dann hast du leider noch nichts geschrieben, dass über einen gewissen Grad
    > an Komplexität hinausgeht.

    Wie flüssig sich die Oberfläche der Anwendung bedienen lässt, hat nicht unbedingt etwas mit der Komplexität zu tun. Wir haben für einen Kunden eine App in Objective-C und eine mit Phonegap/Javascript umgesetzt, beide lassen sich exakt gleich flüssig bedienen, letztere startet allerdings etwas langsamer/länger.

  16. Re: Träge trotz mehr PS

    Autor: scrumm3r 14.07.11 - 09:12

    Das ist schön für euch, sagt aber noch nichts über die Komplexität aus. Spätestens wenn es um größere Datenmengen und/oder etwas kompliziertere Grafiken geht, hat JavaScript eindeutig das Nachsehen. Beides war bei euch wohl nicht der Fall. Ich muss also davon ausgehen, dass ihr minderkomplexe Anforderungen umzusetzen hattet.

  17. Re: Träge trotz mehr PS

    Autor: Schnarchnase 14.07.11 - 09:23

    scrumm3r schrieb:
    --------------------------------------------------------------------------------
    > Das ist schön für euch, sagt aber noch nichts über die Komplexität aus.

    Ich würde sagen beide Anwendungen sind recht komplex, es sind jedenfalls keine 0815-Apps die man mal schnell runtergeschrieben hat.

    > Spätestens wenn es um größere Datenmengen und/oder etwas kompliziertere
    > Grafiken geht, hat JavaScript eindeutig das Nachsehen.

    Große Datenmengen haben absolut nichts mit Komplexität zu tun.

  18. Re: Träge trotz mehr PS

    Autor: scrumm3r 14.07.11 - 09:29

    Insofern du mit den Datenmengen was kompliziertes machst, schon. Einen Auswertungsalgorithmus für nicht vernachlässigbare Datenmengen mit grafischer Darstellung auf einem Telefon performant zu bekommen, ist jedenfalls mit Objective-C deutlich besser machbar, als mit JavaScript. In solche Fällen zeigt sich sehr schnell, dass es da um stellenweise im den Faktor 1000 geht, den JavaScript langsamer ist, als eine kompilierte Programmiersprache.

    Selbst mit den neuesten VMs ist das so.

  19. Re: Leider falsch

    Autor: Yeeeeeeeeha 14.07.11 - 09:37

    Macht Titanium nicht so eine seltsame JS-Native-Verschwurbelung? Irgendwie machen die immer Werbung mit dem Wort "native", was genau das in dem Moment bedeutet, habe ich aber noch nicht herausgefunden. Wie läuft das denn da?

    Yeeeeeeeeha - Nur echt mit 2^3 e
    Perl-Monk, Java-Trinker, Objective-C Wizard, PHP-Kiddie, unfreiwilliger FreeBSD-/Linux-Teilzeitadmin

  20. Re: Leider falsch

    Autor: scrumm3r 14.07.11 - 09:56

    Titanium benutzt native UI-Elemente. D.h. du musst die Konfiguration und das Styling des UI und stellenweise ein paar Events für jede Zielplattform neu schreiben. Das Ergebnis verhält sich deutlich performanter als JS in Verbindung mit HTML. Zudem muss man nicht alles eigenhändig nachbasteln.
    Zu meiner Erheiterung musste ich schon einige Male feststellen, dass die Verwendung von JavaScript zusammen mit Titanium oder PhoneGap die Entwicklungszeit nicht verkürzt. Unter der Voraussetzung, dass man die APIs gut kennt und weiß, was man tut, entwickelt es sich mit den plattform-nativen Sprachen und APIs (Android -> Java/XML, iOS -> Obj-C) immer deutlich schneller, als mit einem Drittanbieter-Aufsatz.

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Delta Energy Systems (Germany) GmbH, Teningen
  2. Klinikum Nürnberg, Nürnberg
  3. Interhyp Gruppe, München
  4. Bundesamt für Sicherheit in der Informationstechnik, Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. mit Logitech-Angeboten, z. B. G900 Chaos Spectrum für 79€ statt über 100€ im Vergleich)
  2. 99,90€ + Versand (Vergleichspreis 140€)
  3. 149,90€ + Versand (im Preisvergleich ab 184,95€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Yuneec H520: 3D-Modell aus der Drohne
Yuneec H520
3D-Modell aus der Drohne

Multikopter werden zunehmend auch kommerziell verwendet. Vor allem machen die Drohnen Luftbilder und Inspektionsflüge und vermessen. Wir haben in der Praxis getestet, wie gut das mit dem Yuneec H520 funktioniert.
Von Dirk Koller


    IT: Frauen, die programmieren und Bier trinken
    IT
    Frauen, die programmieren und Bier trinken

    Fest angestellte Informatiker sind oft froh, nach Feierabend nicht schon wieder in ein Get-together zu müssen. Doch was ist, wenn man kein Team hat und sich selbst Programmieren beibringt? Women Who Code veranstaltet Programmierabende für Frauen, denen es so geht. Golem.de war dort.
    Von Maja Hoock

    1. Software-Entwickler CDU will Online-Weiterbildung à la Netflix
    2. Job-Porträt Cyber-Detektiv "Ich musste als Ermittler über 1.000 Onanie-Videos schauen"
    3. Bundesagentur für Arbeit Ausbildungsplätze in der Informatik sind knapp

    IMHO: Valves Ka-Ching mit der Brechstange
    IMHO
    Valves "Ka-Ching" mit der Brechstange

    Es klingelt seit Jahren in den Kassen des Unternehmens von Gabe Newell. Dabei ist die Firma tief verschuldet - und zwar in den Herzen der Gamer.
    Ein IMHO von Michael Wieczorek

    1. Artifact im Test Zusammengewürfelt und potenziell teuer
    2. Artifact Erste Kritik an Kosten von Valves Sammelkartenspiel
    3. Virtual Reality Valve arbeitet an VR-Headset und Half-Life-Titel

    1. 2nd Life: Ausgemusterte Bus-Akkus speichern jetzt Solarenergie
      2nd Life
      Ausgemusterte Bus-Akkus speichern jetzt Solarenergie

      Was wird mit den Unmengen von entsorgten Akkus aus Elektroautos und Bussen passieren? Volvo macht in Schweden bei einem Forschungsprojekt mit, bei dem gebrauchte Bus-Akkus in ihrer zweiten Lebenshälfte als Stromspeicher von Photovoltaikanlagen dienen.

    2. Paketlieferungen per Drohne: Amazon hat sein Versprechen nicht gehalten
      Paketlieferungen per Drohne
      Amazon hat sein Versprechen nicht gehalten

      Da hat sich Amazon-Chef Jeff Bezos verkalkuliert. Vor fünf Jahren hatte er angekündigt, dass allerspätestens ab diesem Jahr Drohnen Amazon-Pakete zu den Kunden fliegen. Der Plan wird weiter verfolgt - die Deutsche Post ist aber skeptisch.

    3. Fehler, Absturz oder Problem: Verbotene Wörter im Apple Store
      Fehler, Absturz oder Problem
      Verbotene Wörter im Apple Store

      Absturz, Fehler oder Problem: Diese Wörter sind für Mitarbeiter im Apple Store tabu, wenn es um technische Fehler von Apple-Produkten geht. Stattdessen sollen die Mitarbeiter zwar verständnisvoll sein, aber keinesfalls die Produkte als Grund für die Probleme benennen.


    1. 13:30

    2. 12:24

    3. 11:45

    4. 11:15

    5. 09:00

    6. 13:57

    7. 13:20

    8. 12:45