Push-Nachrichten von MacTechNews.de

Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

MacBook Pro, M1 Max und Xcode – Was bedeutet die enorme Performance für Entwickler?

Es steht inzwischen außer Frage, dass sowohl der M1 Pro als auch der M1 Max wahre Leistungsmonster sind. In allen bislang durchgeführten Benchmarktests kommen die Chips auf Werte, wie man sie nur bei wesentlich stromhungrigeren Prozessoren und Grafikkarten vorfindet. Die Vorzüge der 2020 gezeigten M1-Chips kommen dabei noch stärker zum Tragen, denn nun befindet sich Apple auch absolut gesehen an der Spitze des Leistungsspektrums. In diesem Artikel werfen wir einen Blick darauf, was die neuen Möglichkeiten für die alltägliche Arbeiten bedeuten – in unserem Beispiel geht es konkret um Software-Entwicklung.

Kompilieren in Xcode – am Beispiel von MacStammbaum 9
MacStammbaum 9 ist ein riesiges Projekt mit als einer Million Zeilen Code. Die Software setzt auf zahlreiche aktuelle Apple-Frameworks, so zum Beispiel Metal, SceneKit, CoreAnimation, CloudKit, CoreML und AVFoundation.

Normalerweise muss in Xcode selten ein Projekt komplett neu kompiliert werden – meist werden nur die geänderten Dateien kompiliert und die App ist startfertig. Doch von Zeit zu Zeit ist dies erforderlich – entweder, weil globale Header-Dateien geändert oder grundlegende Projekteinstellungen angepasst wurden. Bei großen Projekten bedeutet dies normalerweise: Lüfterlärm und Kaffeepause. Doch bereits der M1-Chip hat die Situation für Xcode-Entwickler mit großen Projekten maßgeblich verbessert – und der M1 Max legt nach unseren Messungen noch eine Schippe drauf:

Unser Test ist simpel: Wir löschen den Inhalt des "Derived Data"-Ordners, in welchem Xcode Zwischenstände abspeichern, starten Xcode und kompilieren daraufhin das Projekt MacStammbaum. Die Performance ist gewaltig: Ein M1 Max benötigt nur 1:18, während sich die beiden (etwas älteren) Intel-MacBooks 7 Minuten und mehr Zeit nehmen.

Fast noch wichtiger: Kein Lärm!
Das MacBook Pro 2014 und 2016 fangen bereits nach etwa 30 Sekunden an, die Lüfter auf Höchstdrehzahl zu betreiben. Anders der Mac mini M1 und das MacBook Pro 16" mit M1 Max: Hier ist noch nicht einmal eine maßgebliche Erwärmung des Gehäuses festzustellen – geschweige denn Lüftergezeter.

Selbst wenn man das MacStammbaum-Projekt 5x hintereinander kompiliert, bleibt das MacBook Pro mit M1 Max angenehm kühl. Auch beim Auschecken von größeren Projekte aus einer Versionsverwaltung (hier GIT) ist mit keiner Wärme- oder Lärmbelästigung zu rechnen – selbst wenn mehrere Vorgänge parallel laufen. Und auch das Entpacken von Xcode (wenn man es nicht aus dem Mac App Store lädt) ist mit keinem Lüfterkonzert mehr verbunden.

Autovervollständigung in Xcode
Die Autovervollständigung in Xcode wird mit zunehmender Projektgröße immer träger: Beispielsweise dauert es auf den beiden hier getesteten Intel-MacBook manchmal 5 Sekunden und mehr, bis Xcode die Autovervollständigungen präsentiert. Bereits bei einem Mac mini mit M1 ist das Problem allerdings fast verschwunden: Nach einer Sekunde ist stets das Fenster mit den Auto-Vervollständigungen auf dem Bildschirm zu sehen.

Und beim M1 Max gibt es selbst beim großen MacStammbaum-Projekt keine merkliche Verzögerung mehr, bis Xcode die Vorschlagsliste einblendet – es funktioniert so, als würde das Projekt aus ein paar dutzend Code-Dateien bestehen und nicht aus mehreren Tausend.

Noch eine Anmerkung bezüglich der Auto-Vervollständigung: Glücklicherweise gestaltete Apple die Escape-Taste der neuen MacBooks sehr groß – über diese löst man nämlich in Xcode die Auto-Vervollständigung aus.

Zu schneller Mac für Entwickler gefährlich
Meist verwendet ein Entwickler auch den Mac zum Testen und Ausprobieren, welchen er zum entwickeln nutzt. Will man aktuell eine Mac-App herausbringen, welche unter Catalina, Big Sur und Monterey laufen soll, muss man eine gewaltige Spanne an Macs abdecken: Die App hat auch auf einem MacBook Air von 2012 (mit 4 GB RAM!) gut zu funktionieren. Nutzt der Entwickler also beispielsweise einen M1 oder gar M1 Max, fallen vielleicht kaum Flaschenhälse auf, welche aber auf einem älteren MacBook die App unter Umständen unbenutzbar machen. Insofern ist die gewaltige Performance des M1 Max während der Entwicklung ein Gottesgeschenk, beim Optimieren aber mitunter hinderlich. Möglicherweise funktionieren Programmelemente auf dem M1 Max in ausreichender Geschwindigkeit – jedoch auf älteren Macs äußerst zäh.

Fazit
Die neuen 2021er MacBook-Pro-Modelle sind für Entwickler fast ideal: Die Performance ist spektakulär, die Lüfter sind nicht wahrnehmbar und auch bei der Nutzung mit mehreren externen Bildschirmen sind keine Geschwindigkeitsprobleme feststellbar. Selbst das Preis-/Leistungsverhältnis ist sehr gut: Musste man vorher für derartige Leistungswerte einen Mac Pro oder iMac Pro ordern, stoßen nun die neuen portablen Geräte in ähnliche Leistungssphären vor – zu einem deutlich geringeren Preis und als portables Gerät.

Ohne Abo: Microsoft veröffentlicht Office 2024 ...

Leak aus macOS Sequoia: Apple bestätigt neuen M...

Gegenüberstellung: AirPods 4 vs. AirPods Pro 2

10 Jahre Yosemite-Design

Vor 10 Jahren: Das iPhone 6 und "Bendgate"

Test AirPods Pro 2

Apples Eskalationskurs und Gebühren-Wirrwarr

Kopplung "iPhone + Apple Watch" sowie Anbindung...

Kommentare

MacRS03.11.21 11:57

Wegen dem "auf zu schnellen Rechnern entwickeln" Thema. Der richte Weg ist aus meiner Sicht nicht das benutzen von lahmen Rechnern zum Entwickeln, sondern eben das Testen der Software auf lahmen Rechnern unabhängig von der reinen Entwicklung. Wofür hat man sonst ein studentisches Herr in der QA-Abteilung

Rosember03.11.21 11:59

Bisher haben Hardware-Leistungsschübe immer zu einem Überverbrauch der Zuwächse auf Seiten der Software geführt - sei es durch Disziplinlosigkeit, sei es durch angeturnt sein von den neuen Möglichkeiten.
Ehrlich gesagt bereitet mir das Sorge - und nicht nur auf persönlichem Gebiet, wo eventuell Investitionen in Neugeräte erforderlich werden könnten, die bisher (Intel) seit rund zehn Jahren stabil allen Neuentwicklungen gerecht werden. Auch in Punkto Umweltbelastung und Ressourcenverbrauch sehe ich Gefahren. Denn auf einmal könnten prinzipiell noch gut funktionierende Geräte neuen Softwareanforderungen nicht mehr genügen und entsorgt werden müssen, ohne dass tatsächlich ein funktioneller oder Performancegewinn zu beobachten wäre - wir kennen das aus der Zeit bis ca. 2010 als ein Rechner durchschnittlich nach 3 Jahren zu langsam geworden war, um eigentlich altbekannte Aufgaben weiterhin erledigen zu können. Ich denke dabei vor allem an Standardanwendungen wie Office u.Ä.
Kurz gesagt: Ich möchte alle Softwareentwickler bitten und auffordern, die nun mögliche Rechenleistung wirklich nur dann einzufordern, wenn das unumgänglich ist.

Mendel Kucharzeck03.11.21 12:09

MacRS
Wenns aber den Entwickler selbst ärgert, wie langsam eine bestimmte Funktion ist, wird's mit SICHERHEIT schneller behoben als wenns nur QA ärgert

Rosember
Manchmal ist das Abschneiden alter Zöpfe aber notwendig: Überleg mal, das aktuelle macOS würde noch immer auf Grafikkarten laufen, welche kein Metal unterstützen. Entwickler hätten dann doppelt Arbeit, Metal und OpenGL zu unterstützen – und würden sich vielleicht gar nicht die Arbeit machen, und Compute-Geschichten gleich auf der CPU ausführen. So können Entwickler von einem bestimmten Funktionsumfang des Macs ausgehen.

MacRS03.11.21 12:12

Mendel Kucharzeck

MacRS
Wenns aber den Entwickler selbst ärgert, wie langsam eine bestimmte Funktion ist, wird's mit SICHERHEIT schneller behoben als wenns nur QA ärgert

Das stimmt mit Sicherheit. Aber dafür willst Du nicht die ganze Zeit mit einer ollen Kiste arbeiten, oder?

Mendel Kucharzeck03.11.21 12:14

MacRS
Klar, natürlich nicht. Was ich mit dem Absatz in der News sagen wollte: Manchmal fallen so dem Entwickler nicht direkt bei der Entwicklung problematische Methoden auf, weil der M1 Max einfach ein gigantisches Übermaß an Performance mitbringt.

Stefan S.03.11.21 12:32

Was anderes:

Die neuen MacBook-Pro-Modelle kommen mit Klinkenbuchse (auch) für hochohmige Kopfhörer. (Liest hier Sonorman mit?)

-2

Rosember03.11.21 12:33

Mendel Kucharzeck

Rosember
Manchmal ist das Abschneiden alter Zöpfe aber notwendig: Überleg mal, das aktuelle macOS würde noch immer auf Grafikkarten laufen, welche kein Metal unterstützen. Entwickler hätten dann doppelt Arbeit, Metal und OpenGL zu unterstützen – und würden sich vielleicht gar nicht die Arbeit machen, und Compute-Geschichten gleich auf der CPU ausführen. So können Entwickler von einem bestimmten Funktionsumfang des Macs ausgehen.

Manchmal. Aber eben nur manchmal. Dreifach eingesprungene Menü-Animationen und ähnlicher Quatsch gehörten sicher nie dazu. Und z.B. werde ich nie irgendwelchen AR-Kram brauchen, um meine Text- und Tabellenkalkulationen vorzunehmen.
Ehrlich gesagt, habe ich das Gefühl, dass sich die Rechner bald noch stärker und vielleicht inkompatibler als bisher in die - ja bereits vorhandenen - Klassen der Hochleistungs- (vereinfachend: M1Pro und -max) und Normalrechner (M1, Intel, AMD) aufspalten werden. Jedenfalls habe ich kürzlich in einer Rezension der neuen MBPros erstmals gelesen, dass sich der Rezensent - ein Fotograf - nicht einmal vorstellen konnte, wozu er die Power der Rechner jemals einsetzen können sollte.
Aber vielleicht haben wir uns auch einfach nur an den leistungsmäßigen Stillstand der letzten Inteljahre gewöhnt?

Mendel Kucharzeck03.11.21 12:38

Rosember
Bei einem Punkt gebe ich dir recht: Heute weiss die Consumer-Software oftmals nicht, mit der verfügbaren Power etwas anzufangen – was früher ja ganz anders war: Dort haperte es meist an der verfügbaren Performance.

Mendel Kucharzeck03.11.21 12:39

Stefan S.

Die neuen MacBook-Pro-Modelle kommen mit Klinkenbuchse (auch) für hochohmige Kopfhörer. (Liest hier Sonorman mit?)

Hatten wir doch schon lange:

Unwindprotect03.11.21 12:48

Mendel Kucharzeck

MacRS
Wenns aber den Entwickler selbst ärgert, wie langsam eine bestimmte Funktion ist, wird's mit SICHERHEIT schneller behoben als wenns nur QA ärgert

Oder es dauert gleich weeeeeitaus länger, weil das Unternehmen erst einen neuen Entwickler einstellen und anlernen muss. Der mit der langsamen alten Kiste geplagte Entwickler ist dann nämlich schon gegangen und hat sich eine Firma gesucht, die bei der technischen Ausstattung nicht knausert

LoCal03.11.21 12:52

MacRS

Die Entwickler bei Be, Inc. bekamen damals nur die Hälfte des RAMs in die Arbeitsrechner eingebaut, die BeOS selbst forderte … damit sie nicht verschwenderisch mit Ressourcen umgehen.

Ich hab zwar keine Lösung, doch ich bewundere dein Problem

pstoehr03.11.21 13:00

Vielen Dank für den aufschlussreichen Test!

Unwindprotect03.11.21 13:00

LoCal

Die Entwickler bei Be, Inc. bekamen damals nur die Hälfte des RAMs in die Arbeitsrechner eingebaut, die BeOS selbst forderte … damit sie nicht verschwenderisch mit Ressourcen umgehen.

Tja... und man sieht ja was draus wurde 🤣

LoCal03.11.21 13:18

Unwindprotect

LoCal

Die Entwickler bei Be, Inc. bekamen damals nur die Hälfte des RAMs in die Arbeitsrechner eingebaut, die BeOS selbst forderte … damit sie nicht verschwenderisch mit Ressourcen umgehen.

Tja... und man sieht ja was draus wurde 🤣

Zur damaligen Zeit war BeOS in vielen Belangen, besonders was die Performance angeht, allen Betriebssystem weit voraus. Man erinnere sich nur an die 3D-Objekte auf die man Filme ziehen konnte, die dann, angepasst an die aktuelle Geometrie, perfekt weiterspielten.
Auch war Be, Inc allen anderen voraus was tragbare Geräte mit Internetverbindung …also iPad … dafür schuf Be eine Plattform die damals Richtungsweisend war.

Aber trotzdem ging Be den Bach runter und die Gründe dafür sind:
- Apple entschied sich für NeXT statt Be, Inc. (was ich durchaus verstehe und ich selbst habe ja einen großen Hang zu NeXT und ObjC)
Be, Inc. machte einige Fehler wie z.B.:
-- BeOS wurde zugunsten von Stinger komplett eingestellt
-- Stinger wurde nicht für Entwickler geöffnet

- Software für BeOS bzw. Stinger war schwieriger zu programmieren als für NeXTStep /

OpenStep (woraus ja OS X und iPhoneOS/iOS hervorging)

Bis auf die schwierigere Programmierung war der Untergang von BeOS kein technischer, sondern ausschliesslich strategische Fehler.

Ich hab zwar keine Lösung, doch ich bewundere dein Problem

milk03.11.21 14:21

LoCal

Bis auf die schwierigere Programmierung war der Untergang von BeOS kein technischer, sondern ausschliesslich strategische Fehler.

BeOS war beeindruckend damals, das steht vollkommen außer Frage. Ich mochte das sehr und habe mehr als einmal einen Umstieg erwogen. Aber trotz der hohen Versionsnummern war das OS eine Betaversion, und auch Be ist in die Falle gelaufen, zwischendrin zu sehr an den APIs zu schrauben, so dass die elegante Architektur der ersten Releases relativ schnell schon an manchen Stellen zu Wildwuchs wurde.

Damals war ich noch kein Softwareentwickler, deshalb kann ich nicht sagen, ob für BeOS zu programmieren so viel schwerer war als für OpenStep. Denn wenn man ausschließlich die APIs und Tools von OpenStep 4 zum Vergleich heranzieht und nicht, was mit den Jahrzehnten daraus wurde: Die waren auch nicht ganz einfach. Zumindest das kann ich mit Sicherheit sagen, weil ich vor wenigen Jahren nochmal eine Zeitlang für und mit OpenStep entwickeln durfte.

cfkane03.11.21 14:24

Hatte damals BeOS auch sehr gemocht (wer sich den aktuellen Stand ansehen möchte: HaikuOS .

Aber es wollten wohl doch zu wenige sich extra Hardware dafür anschaffen. Und die Intel-Portierung kam spät.

Als Student hatte ich damals zwei BeOS-Vorführungen besucht.
Bei der ersten hatten noch viele über die Geschwindigkeit gestaunt: Wowww
Bei der zweiten kam nur ein Achselzucken: Kann mein Windows-PC auch.

Das Entwickeln hat wohl einfach zu lange gedauert. Ein komplettes Betriebssystem ist halt eine Riesenaufgabe. Siehe auch, wie lange Apple gebraucht hat, um aus dem eigentlich fertigen OPENSTEP eine alltagsfähige Mac-Version zu schaffen.

macfreakz03.11.21 14:52

Das Simulator sollte auch noch CPU Throttling einbauen, auch für Mac Apps. Damit wäre das Problem gelöst.

MacRS03.11.21 14:55

macfreakz

Das Simulator sollte auch noch CPU Throttling einbauen, auch für Mac Apps. Damit wäre das Problem gelöst.

Unthrottled - 10% slower | 20% slower | 30% slower | .... Intel speed

cuco03.11.21 15:17

MacRS

macfreakz

Das Simulator sollte auch noch CPU Throttling einbauen, auch für Mac Apps. Damit wäre das Problem gelöst.

Unthrottled - 10% slower | 20% slower | 30% slower | .... Intel speed

Es ist leicht eine 5 Jahre alte CPU mit einer Brandneuen zu vergleichen. Und mal ehrlich gesagt, es ist nicht Apples verdienst, dass die ARM Architektur so gut skalliert. Ja, Apple CPUs sind super schnell und energieeffizient. Aber das ist nur zu geringem Anteil Apples verdienst. Das ist ARM Architektur.
Kannst ja mal versuchen ob die ARM CPUs noch Land sehen wenn man eine x86 AVX512 Anwendung ausführen würde.
Ich glaube das haben schon einige erwähnt. X86 ist eine andere Welt mit einem viel breiteren Software und Anwendungsfeld. Man schleppt den ganzen alten Ballast mit.
ARM ist davon komplett frei.

ergänzend: | ......ARM Inkompatibel :'(

-13

Mendel Kucharzeck03.11.21 15:19

cuco
Warum existiert dann aber kein anderer Chip, der mit den A-Prozessoren oder M-Chips mithalten kann?

cuco03.11.21 15:21

Mendel Kucharzeck

cuco
Warum existiert dann aber kein anderer Chip, der mit den A-Prozessoren oder M-Chips mithalten kann?

Ist das eine ernst gemeinte Frage? Weil es außer in der Apple Blase nicht genügend optimierte Software gibt. Und weil sich der Rest der Welt nicht komplett neue Hardware leisten kann.
Es gibt keinen anderen großen Chiphersteller. Man müsste erst mal an AMD und Intel und der aktuellen x86 Welt vorbeiziehen.

Apple hat das Problem in seiner Software/Hardware Blase nicht.

-12

Mendel Kucharzeck03.11.21 15:23

cuco
Ja, die Frage ist ernst gemeint. Die ganze Android-Welt, inkl. High-End-Smartphones, sind auch ARM-Chips (z.B. von Qualcomm). Warum sind die dann so viel langsamer als die A-Chips wenn Apple nichts am Chip-Design geändert hat?

Und in der Android-Welt ist alles ARM – daher gibt es dort wohl genug Software

MetallSnake03.11.21 15:49

cuco

Ja, Apple CPUs sind super schnell und energieeffizient. Aber das ist nur zu geringem Anteil Apples verdienst. Das ist ARM Architektur.

Wer hat noch gleich zusammen mit Acorn und VLSI ARM Ltd. gegründet? 🤔

Das Schöne an der KI ist, dass wir endlich einen Weg gefunden haben, wie die Wirtschaft weiter wachsen kann, nachdem sie jeden Einzelnen von uns getötet hat.

milk03.11.21 15:52

MetallSnake

Wer hat noch gleich zusammen mit Acorn und VLSI ARM Ltd. gegründet? 🤔

Spielverderber. Ich wollte jetzt mal abwarten, wie lange die Unwissenden, die aber scheinbar die Weisheit mit Löffeln, ihr wisst schon, sich hier noch die Köpfe einschlagen.

Michael Lang aus Rieder03.11.21 18:52

Ja, Apple CPUs sind super schnell und energieeffizient. Aber das ist nur zu geringem Anteil Apples verdienst. Das ist ARM Architektur.

Aber keiner der konkurrierenden ARM-CPU Produzenten (es gibt genug im Android-Lager) kommt an die <Performance der Apple CPUs ran. Und einen so performanten Soc haben die schon gar nicht...

Ich finde schon, dass es Apples Verdienst ist diese Performance aus der ARM Architektur herauszuholen. Dazu gehört die Architektur de SOcs mit zB. unified Memory etc. Das ist ja bei ARM nicht einfach so vorgegeben.

gfhfkgfhfk03.11.21 22:09

Mendel Kucharzeck

Apple hat sich sehr geschickt Vorteile in der Fertigungstechnologie gesichert d.h. 5nm Chips auf den Markt gebracht, während Intel die ganze Zeit noch bei 14nm verharrte. Die meisten ARM Designs sind auch nicht in 5nm gefertigt.

Dann nutzt Apple speziellen Speicher für das UMA Design, was den Speicherausbau stark limitiert, aber dafür mehr Bandbreite liefert. Leider habe ich bisher noch keine brauchbaren Benchmarks zu Apples M1 Systemen gesehen, woraus man Rückschlüsse auf das System machen könnte.

Apple liefert nun maximal 64GB RAM, was für ein Notebook gut ist, aber keinerlei Vergleich mit einem aktuellen Xeon SP 3 standhält. 6TB RAM pro Sockel d.h. max 12TB im System wovon 4TB normales RAM ist, und 8TB spezielles Flash RAM oder halt 8TB normales RAM.

Apple optimiert die CPU dank einer sehr geschickten Zusammenstellung von Funtkionseinheiten auf die Apple eigenen Use-Cases, d.h. FinalCut läuft darauf wirklich perfekt, weil die Hardware optimal auf die Software angepasst wurde. Interessant wird es nun einmal, wenn das nicht mehr der Fall ist.

-mactrix-04.11.21 07:39

Leider kein Wort im Beitrag zu der mißlungenen Notch. Beim 16" MBP scheint die Notch das Xcode Menu nicht zu teilen aber beim 14" Modell schon. Dazu nutzen Entwickler gerne zahlreiche Menu Bar Apps und die kommen sich auf dem 14" MBP dann schnell mit dem geteilten Xcode Menu in die Quere.

Diese Notch ist zu groß. Ich werde warten bis es hier eine Überarbeitung gibt. Die Kritik an der Notch ist massiv, daher wird Apple hier noch mal nachbessern müssen.

-5

Michael Lang aus Rieder04.11.21 16:29

gfhfkgfhfk

Mendel Kucharzeck

Klar hat Apple auch Vorteile bim fertigungsverfahren. Aber der Speed der CPUs ist doch nicht alein auf das fertuguzngsverfahren zurückzuführen, sondern zum Großteil dem Chipdesign (Caches, Speciheranbindung etc.).
Auch nutzt Apple spezielle Funktionseinheiten für AI. Die Applesoft ist perfekt darauf angepaßt.
Das macht ja auch einen Vorteil bei Apple aus hard und Software aus einer Hand, aufeinander abgestimmt.

Aber die Funktionseinheiten kann. auch jeder andere Entwickler nutzen. So wie man bei X86 eben Vektoreinheiten oder die GPU nutzen kann.

Daher sind Apples SOCs auch mit anderer Software schnell. Wenn diese auf die M1 Architektur optimiert sind, dann geht es noch was schneller...
Das ist anderswo auch so.

Man kann es drehen und wenden, aber unbestritten bleibt, dass Apples Mx-Architektur sehr effizient ist und sehr gute Performance liefert. Über Alles gesehen und ganz besonders pro Watt. Und diese Performace basierend auf ARM liefert derzeit nur Apple.

esi05.11.21 17:40

Mendel Kucharzeck

An Performance hapert es noch immer.

Die meisten Programme nutzen die vielen Kerne nicht im Ansatz aus. Das führt dazu, dass sich ein neuer PC kaum schneller anfühlt, als ein 10 Jahre alter. Die Performance der einzelnen Kerne ist ja auch kaum gesteigert worden. Hinzu kommt, dass Software sukzessive langsamer wird.

Die Finanzen100-App für das iPhone ist so ein Beispiel. Am iPhone 4 (mein erstes iPhone) scrollte die erste Version butterweich. Mit jedem Update wurde das dann ruckeliger, ohne dass es neue Funktionen gegeben hätte. nach Umstieg aufs iPhone 5 war es dann wieder butterweich, und das Spiel fing von vorne an.

Deshalb schließe ich mich der Forderung an: Liebe Softwareentwickler, verschwendet bitte keine Rechenleistung.

MacBook Pro, M1 Max und Xcode – Was bedeutet die enorme Performance für Entwickler?

Kommentare

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.