Diskussion:MySQL - Versionsgeschichte

TaxonBot: Bot: Austausch veralteter Vorlage: :Vorlage:Archiv Tabelle → :Vorlage:Archiv-Tabelle

2024-10-20T14:26:41Z

Bot: Austausch veralteter Vorlage: Vorlage:Archiv Tabelle → Vorlage:Archiv-Tabelle

← Nächstältere Version		Version vom 20. Oktober 2024, 16:26 Uhr
Zeile 1:		Zeile 1:
	{{Diskussionsseite}}		{{Diskussionsseite}}
	{{Archiv Tabelle}}		{{Archiv-Tabelle}}
	{{Autoarchiv\|Alter=100\|Frequenz=monatlich\|Mindestabschnitte=3\|Ziel='((Lemma))/Archiv'\|Mindestbeiträge=1}}		{{Autoarchiv\|Alter=100\|Frequenz=monatlich\|Mindestabschnitte=3\|Ziel='((Lemma))/Archiv'\|Mindestbeiträge=1}}
	{{Redundanzhinweis\|3=MySQL Cluster\|4=MySQL#Cluster-Technik\|Beginn=März 2008\|Ende=Juni 2008\|Diskussion=Wikipedia:Redundanz/März 2008#MySQL Cluster - MySQL#Cluster-Technik (erledigt)}}		{{Redundanzhinweis\|3=MySQL Cluster\|4=MySQL#Cluster-Technik\|Beginn=März 2008\|Ende=Juni 2008\|Diskussion=Wikipedia:Redundanz/März 2008#MySQL Cluster - MySQL#Cluster-Technik (erledigt)}}

Binbesser: /* Müsste MySQL nicht "Mü"SQL ausgesprochen werden? */ Antwort

2023-07-04T12:23:28Z

Müsste MySQL nicht "Mü"SQL ausgesprochen werden?: Antwort

← Nächstältere Version		Version vom 4. Juli 2023, 14:23 Uhr
Zeile 22:		Zeile 22:
	:Youtubevideo mit Widenius-Interview als Einzelnachweis für die Aussprache im Artikel ergänzt. Also Aussprache "mai". --[[Benutzer:--\|--]] ([[Benutzer Diskussion:--\|Diskussion]]) 13:24, 16. Nov. 2016 (CET)		:Youtubevideo mit Widenius-Interview als Einzelnachweis für die Aussprache im Artikel ergänzt. Also Aussprache "mai". --[[Benutzer:--\|--]] ([[Benutzer Diskussion:--\|Diskussion]]) 13:24, 16. Nov. 2016 (CET)
	:ja das dachte ich auch. --[[Benutzer:Binbesser\|Binbesser]] ([[Benutzer Diskussion:Binbesser\|Diskussion]]) 14:22, 4. Jul. 2023 (CEST)		:ja das dachte ich auch. --[[Benutzer:Binbesser\|Binbesser]] ([[Benutzer Diskussion:Binbesser\|Diskussion]]) 14:22, 4. Jul. 2023 (CEST)
			::oder gleich letter by letter: em, why, es, kyu, el. --[[Benutzer:Binbesser\|Binbesser]] ([[Benutzer Diskussion:Binbesser\|Diskussion]]) 14:23, 4. Jul. 2023 (CEST)
	{{erledigt\|1=[[Spezial:Beiträge/87.123.4.206\|87.123.4.206]] 12:15, 24. Nov. 2016 (CET)}}		{{erledigt\|1=[[Spezial:Beiträge/87.123.4.206\|87.123.4.206]] 12:15, 24. Nov. 2016 (CET)}}

Binbesser: /* Müsste MySQL nicht "Mü"SQL ausgesprochen werden? */ Antwort

2023-07-04T12:22:48Z

Müsste MySQL nicht "Mü"SQL ausgesprochen werden?: Antwort

← Nächstältere Version		Version vom 4. Juli 2023, 14:22 Uhr
Zeile 21:		Zeile 21:
	:Wie man den Vornamen ausspricht, weiß ich nicht. Selbst wenn der "Mü" ausgesprochen werden sollte, ist das bei "MySQL" anders. Über die Gründe können wir jetzt viel mutmaßen, was den Artikel ohne reputable Quelle nicht weiterbringt. Meine persönliche Theoriefindung ist, dass der Begriff deshalb "My" wie "mein" ausgesprochen wird, weil er im Englischen benutzt und "my" dort nunmal so ausgesprochen wird. --[[Spezial:Beiträge/87.123.26.109\|87.123.26.109]] 16:20, 22. Okt. 2016 (CEST)		:Wie man den Vornamen ausspricht, weiß ich nicht. Selbst wenn der "Mü" ausgesprochen werden sollte, ist das bei "MySQL" anders. Über die Gründe können wir jetzt viel mutmaßen, was den Artikel ohne reputable Quelle nicht weiterbringt. Meine persönliche Theoriefindung ist, dass der Begriff deshalb "My" wie "mein" ausgesprochen wird, weil er im Englischen benutzt und "my" dort nunmal so ausgesprochen wird. --[[Spezial:Beiträge/87.123.26.109\|87.123.26.109]] 16:20, 22. Okt. 2016 (CEST)
	:Youtubevideo mit Widenius-Interview als Einzelnachweis für die Aussprache im Artikel ergänzt. Also Aussprache "mai". --[[Benutzer:--\|--]] ([[Benutzer Diskussion:--\|Diskussion]]) 13:24, 16. Nov. 2016 (CET)		:Youtubevideo mit Widenius-Interview als Einzelnachweis für die Aussprache im Artikel ergänzt. Also Aussprache "mai". --[[Benutzer:--\|--]] ([[Benutzer Diskussion:--\|Diskussion]]) 13:24, 16. Nov. 2016 (CET)
			:ja das dachte ich auch. --[[Benutzer:Binbesser\|Binbesser]] ([[Benutzer Diskussion:Binbesser\|Diskussion]]) 14:22, 4. Jul. 2023 (CEST)
	{{erledigt\|1=[[Spezial:Beiträge/87.123.4.206\|87.123.4.206]] 12:15, 24. Nov. 2016 (CET)}}		{{erledigt\|1=[[Spezial:Beiträge/87.123.4.206\|87.123.4.206]] 12:15, 24. Nov. 2016 (CET)}}

TaxonBot: Bot: 1 Abschnitt nach Diskussion:MySQL/Archiv#Quellen veraltet archiviert – letzte Bearbeitung: Diaspomod (20.02.2020 21:54:44)

2020-02-29T23:25:35Z

Bot: 1 Abschnitt nach Diskussion:MySQL/Archiv#Quellen veraltet archiviert – letzte Bearbeitung: Diaspomod (20.02.2020 21:54:44)

← Nächstältere Version		Version vom 1. März 2020, 01:25 Uhr
Zeile 3:		Zeile 3:
	{{Autoarchiv\|Alter=100\|Frequenz=monatlich\|Mindestabschnitte=3\|Ziel='((Lemma))/Archiv'\|Mindestbeiträge=1}}		{{Autoarchiv\|Alter=100\|Frequenz=monatlich\|Mindestabschnitte=3\|Ziel='((Lemma))/Archiv'\|Mindestbeiträge=1}}
	{{Redundanzhinweis\|3=MySQL Cluster\|4=MySQL#Cluster-Technik\|Beginn=März 2008\|Ende=Juni 2008\|Diskussion=Wikipedia:Redundanz/März 2008#MySQL Cluster - MySQL#Cluster-Technik (erledigt)}}		{{Redundanzhinweis\|3=MySQL Cluster\|4=MySQL#Cluster-Technik\|Beginn=März 2008\|Ende=Juni 2008\|Diskussion=Wikipedia:Redundanz/März 2008#MySQL Cluster - MySQL#Cluster-Technik (erledigt)}}

	== Quellen veraltet ==

	Die Quelle http://www.mysql.de/why-mysql/marketshare/ war veraltet (404) - habe sie bis auf Weiteres aus den Quellen gelöscht. Ist die genannte Seite evtl. nur umgezogen? Weiß jemand was darüber? --[[Spezial:Beiträge/2A02:8109:83C0:1959:6DCF:B3E9:6365:5BC1\|2A02:8109:83C0:1959:6DCF:B3E9:6365:5BC1]] 21:36, 8. Feb. 2015 (CET)

	== {{Anker\|deadurl_2015-10}} Defekte Weblinks ==		== {{Anker\|deadurl_2015-10}} Defekte Weblinks ==

Diaspomod: /* Portabler Quellcode */

2020-02-20T20:54:44Z

Portabler Quellcode

← Nächstältere Version		Version vom 20. Februar 2020, 22:54 Uhr
Zeile 52:		Zeile 52:
	::Aber da wir jetzt eh d'accord sind, was die gekürzte Version anbelangt, gibts eh nix zu streiten :-) --[[Benutzer:Sebastian.Dietrich\|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich\|<big>✉</big>]] 12:45, 20. Feb. 2020 (CET)		::Aber da wir jetzt eh d'accord sind, was die gekürzte Version anbelangt, gibts eh nix zu streiten :-) --[[Benutzer:Sebastian.Dietrich\|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich\|<big>✉</big>]] 12:45, 20. Feb. 2020 (CET)

	::: Dass man mit Java auch hinsichtlich Performance besser dran wäre halte ich für etwas zu tendenziös. Es gibt ja Gründe, warum Oracle seit Jahren am "Project Valhalla" arbeitet. Es gibt auch Gründe, warum die Sprache Rust von Mozilla angetrieben wird. Die Sprache C++ hat sich auch seit spätestens 2011 (C++11) modernisiert. Nur ist das Marketing-technisch noch nicht überall bekannt geworden. Es gibt Datenbanken wie MySQL auch in Containern, wie z.B. Docker. Diese Container sind plattformunabhängig, da sie z.B. auch direkt in Windows einsetzbar sind. In Zukunft ist eine Kompilierung in WebAssembly + WASI denkbar, dann hat man auch einen plattformneutralen Bytecode vergleichbar zur JVM. Es gibt ~~nicht~~ ~~portablen Quellcode~~ im Sinne, dass diese nicht portabel kompilierbar sind. Beispiel ist z.B. "systemd", das Linux-spezifische Schnittstellen nutzt, die auch nicht SUS- oder POSIX-konform sind. Aber ansonsten gibt es auch von mir keine Streitpunkte mehr. --[[Benutzer:Diaspomod\|Diaspomod]] ([[Benutzer Diskussion:Diaspomod\|Diskussion]]) 13:16, 20. Feb. 2020 (CET)		::: Dass man mit Java auch hinsichtlich Performance besser dran wäre halte ich für etwas zu tendenziös. Es gibt ja Gründe, warum Oracle seit Jahren am "Project Valhalla" arbeitet. Es gibt auch Gründe, warum die Sprache Rust von Mozilla angetrieben wird. Die Sprache C++ hat sich auch seit spätestens 2011 (C++11) modernisiert. Nur ist das Marketing-technisch noch nicht überall bekannt geworden. Es gibt Datenbanken wie MySQL auch in Containern, wie z.B. Docker. Diese Container sind plattformunabhängig, da sie z.B. auch direkt in Windows einsetzbar sind. In Zukunft ist eine Kompilierung in WebAssembly + WASI denkbar, dann hat man auch einen plattformneutralen Bytecode vergleichbar zur JVM. Es gibt nichtportable Quellcodes im dem Sinne, dass diese nicht portabel für mehrere Plattformen kompilierbar sind. Beispiel ist z.B. "systemd", das Linux-spezifische Schnittstellen nutzt, die auch nicht SUS- oder POSIX-konform sind. Aber ansonsten gibt es auch von mir keine Streitpunkte mehr. --[[Benutzer:Diaspomod\|Diaspomod]] ([[Benutzer Diskussion:Diaspomod\|Diskussion]]) 13:16, 20. Feb. 2020 (CET)

Diaspomod am 20. Februar 2020 um 12:30 Uhr

2020-02-20T12:30:57Z

← Nächstältere Version		Version vom 20. Februar 2020, 14:30 Uhr
Zeile 52:		Zeile 52:
	::Aber da wir jetzt eh d'accord sind, was die gekürzte Version anbelangt, gibts eh nix zu streiten :-) --[[Benutzer:Sebastian.Dietrich\|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich\|<big>✉</big>]] 12:45, 20. Feb. 2020 (CET)		::Aber da wir jetzt eh d'accord sind, was die gekürzte Version anbelangt, gibts eh nix zu streiten :-) --[[Benutzer:Sebastian.Dietrich\|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich\|<big>✉</big>]] 12:45, 20. Feb. 2020 (CET)

	::: Dass man mit Java auch hinsichtlich Performance besser dran wäre halte ich für etwas zu tendenziös. Es gibt ja Gründe, warum Oracle seit Jahren am "Project Valhalla" arbeitet. Es gibt auch Gründe, warum die Sprache Rust von Mozilla angetrieben wird. Die Sprache C++ hat sich auch seit spätestens 2011 (C++11) modernisiert. Nur ist das Marketing-technisch noch nicht überall bekannt geworden. Es gibt Datenbanken wie MySQL auch in Containern, wie z.B. Docker. Diese Container sind plattformunabhängig, da sie z.B. auch direkt in Windows einsetzbar sind. In Zukunft ist eine Kompilierung in WebAssembly + WASI denkbar, dann hat man auch einen plattformneutralen Bytecode vergleichbar zur JVM. Es gibt nicht portablen Quellcode im Sinne, dass diese nicht portabel kompilierbar sind. Beispiel ist z.B. "systemd", ~~dass~~ Linux-spezifische Schnittstellen nutzt, die auch nicht SUS- oder POSIX-konform sind. Aber ansonsten gibt es auch von mir keine Streitpunkte mehr. --[[Benutzer:Diaspomod\|Diaspomod]] ([[Benutzer Diskussion:Diaspomod\|Diskussion]]) 13:16, 20. Feb. 2020 (CET)		::: Dass man mit Java auch hinsichtlich Performance besser dran wäre halte ich für etwas zu tendenziös. Es gibt ja Gründe, warum Oracle seit Jahren am "Project Valhalla" arbeitet. Es gibt auch Gründe, warum die Sprache Rust von Mozilla angetrieben wird. Die Sprache C++ hat sich auch seit spätestens 2011 (C++11) modernisiert. Nur ist das Marketing-technisch noch nicht überall bekannt geworden. Es gibt Datenbanken wie MySQL auch in Containern, wie z.B. Docker. Diese Container sind plattformunabhängig, da sie z.B. auch direkt in Windows einsetzbar sind. In Zukunft ist eine Kompilierung in WebAssembly + WASI denkbar, dann hat man auch einen plattformneutralen Bytecode vergleichbar zur JVM. Es gibt nicht portablen Quellcode im Sinne, dass diese nicht portabel kompilierbar sind. Beispiel ist z.B. "systemd", das Linux-spezifische Schnittstellen nutzt, die auch nicht SUS- oder POSIX-konform sind. Aber ansonsten gibt es auch von mir keine Streitpunkte mehr. --[[Benutzer:Diaspomod\|Diaspomod]] ([[Benutzer Diskussion:Diaspomod\|Diskussion]]) 13:16, 20. Feb. 2020 (CET)

Diaspomod: /* Portabler Quellcode */

2020-02-20T12:16:43Z

Portabler Quellcode

← Nächstältere Version		Version vom 20. Februar 2020, 14:16 Uhr
Zeile 51:		Zeile 51:
	::Will darüber aber jetzt nicht streiten (da gab es immer schon Glaubenskriege). Beweisen lassen sich nur Performanceaussagen zu Microbenchmarks - auch das ist wesentlich komplexer als man annehmen könnte (auf Grund des "in die Gänge kommen" des Hot-Spot Compilers bei Java), lässt aber darüberhinaus keine Aussage zu Real-World Applikationen zu (wo die Performance meist nicht im Code, sondern in der DB oder der unpassenden Architektur verloren geht)		::Will darüber aber jetzt nicht streiten (da gab es immer schon Glaubenskriege). Beweisen lassen sich nur Performanceaussagen zu Microbenchmarks - auch das ist wesentlich komplexer als man annehmen könnte (auf Grund des "in die Gänge kommen" des Hot-Spot Compilers bei Java), lässt aber darüberhinaus keine Aussage zu Real-World Applikationen zu (wo die Performance meist nicht im Code, sondern in der DB oder der unpassenden Architektur verloren geht)
	::Aber da wir jetzt eh d'accord sind, was die gekürzte Version anbelangt, gibts eh nix zu streiten :-) --[[Benutzer:Sebastian.Dietrich\|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich\|<big>✉</big>]] 12:45, 20. Feb. 2020 (CET)		::Aber da wir jetzt eh d'accord sind, was die gekürzte Version anbelangt, gibts eh nix zu streiten :-) --[[Benutzer:Sebastian.Dietrich\|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich\|<big>✉</big>]] 12:45, 20. Feb. 2020 (CET)

			::: Dass man mit Java auch hinsichtlich Performance besser dran wäre halte ich für etwas zu tendenziös. Es gibt ja Gründe, warum Oracle seit Jahren am "Project Valhalla" arbeitet. Es gibt auch Gründe, warum die Sprache Rust von Mozilla angetrieben wird. Die Sprache C++ hat sich auch seit spätestens 2011 (C++11) modernisiert. Nur ist das Marketing-technisch noch nicht überall bekannt geworden. Es gibt Datenbanken wie MySQL auch in Containern, wie z.B. Docker. Diese Container sind plattformunabhängig, da sie z.B. auch direkt in Windows einsetzbar sind. In Zukunft ist eine Kompilierung in WebAssembly + WASI denkbar, dann hat man auch einen plattformneutralen Bytecode vergleichbar zur JVM. Es gibt nicht portablen Quellcode im Sinne, dass diese nicht portabel kompilierbar sind. Beispiel ist z.B. "systemd", dass Linux-spezifische Schnittstellen nutzt, die auch nicht SUS- oder POSIX-konform sind. Aber ansonsten gibt es auch von mir keine Streitpunkte mehr. --[[Benutzer:Diaspomod\|Diaspomod]] ([[Benutzer Diskussion:Diaspomod\|Diskussion]]) 13:16, 20. Feb. 2020 (CET)

Sebastian.Dietrich: /* Portabler Quellcode */

2020-02-20T11:49:08Z

Portabler Quellcode

← Nächstältere Version		Version vom 20. Februar 2020, 13:49 Uhr
Zeile 50:		Zeile 50:
	::@Java ist langsamer - das stimmte noch im Jahr 2000, ist aber inzwischen schon lange nicht mehr so. Die korrekte Antwort auf "Ist Java langsamer als C oder C++" ist "es kommt darauf an". Der Grund dafür ist, das all die Performanceoptimierungen, die es in C/C++ gibt rein statischer Natur sind. In Java (oder C# etc.) kann zur Laufzeit weitaus mehr bestimmt werden, was optimiert wird. z.B. machen GarbageCollectoren Speicher-Defragmentierung, wodurch kürzere Sprünge und Pointer möglich sind. Oder loop-unfolding, wenn bei einer Schleife zur Laufzeit nur wenige Iterationen nötig sind. Bei trivialen Microbenchmarks bringt sowas noch recht wenig, dennoch gabs schon 2003 Untersuchungen, bei denen sogar bei Microbenchmarks Java besser als C++ abschnitt (siehe z.B. https://shop.heise.de/katalog/daniel-dusentrieb oder http://scribblethink.org/Computer/javaCbenchmark.html). Und seit 2003 hat sich Java gerade hinsichtlich Performance noch deutlich gesteigert. C/C++ hat sicherlich seine Daseinsberechtigung bei hardwarenaher Programmierung wie z.B. embedded devices - da wird es auch performanter sein, aber ansonsten und insbesondere bei großen Applikationen ist man (auch) hinsichtlich Performance mit Java mit höchster Wahrscheinlichkeit besser dran.		::@Java ist langsamer - das stimmte noch im Jahr 2000, ist aber inzwischen schon lange nicht mehr so. Die korrekte Antwort auf "Ist Java langsamer als C oder C++" ist "es kommt darauf an". Der Grund dafür ist, das all die Performanceoptimierungen, die es in C/C++ gibt rein statischer Natur sind. In Java (oder C# etc.) kann zur Laufzeit weitaus mehr bestimmt werden, was optimiert wird. z.B. machen GarbageCollectoren Speicher-Defragmentierung, wodurch kürzere Sprünge und Pointer möglich sind. Oder loop-unfolding, wenn bei einer Schleife zur Laufzeit nur wenige Iterationen nötig sind. Bei trivialen Microbenchmarks bringt sowas noch recht wenig, dennoch gabs schon 2003 Untersuchungen, bei denen sogar bei Microbenchmarks Java besser als C++ abschnitt (siehe z.B. https://shop.heise.de/katalog/daniel-dusentrieb oder http://scribblethink.org/Computer/javaCbenchmark.html). Und seit 2003 hat sich Java gerade hinsichtlich Performance noch deutlich gesteigert. C/C++ hat sicherlich seine Daseinsberechtigung bei hardwarenaher Programmierung wie z.B. embedded devices - da wird es auch performanter sein, aber ansonsten und insbesondere bei großen Applikationen ist man (auch) hinsichtlich Performance mit Java mit höchster Wahrscheinlichkeit besser dran.
	::Will darüber aber jetzt nicht streiten (da gab es immer schon Glaubenskriege). Beweisen lassen sich nur Performanceaussagen zu Microbenchmarks - auch das ist wesentlich komplexer als man annehmen könnte (auf Grund des "in die Gänge kommen" des Hot-Spot Compilers bei Java), lässt aber darüberhinaus keine Aussage zu Real-World Applikationen zu (wo die Performance meist nicht im Code, sondern in der DB oder der unpassenden Architektur verloren geht)		::Will darüber aber jetzt nicht streiten (da gab es immer schon Glaubenskriege). Beweisen lassen sich nur Performanceaussagen zu Microbenchmarks - auch das ist wesentlich komplexer als man annehmen könnte (auf Grund des "in die Gänge kommen" des Hot-Spot Compilers bei Java), lässt aber darüberhinaus keine Aussage zu Real-World Applikationen zu (wo die Performance meist nicht im Code, sondern in der DB oder der unpassenden Architektur verloren geht)
	::Aber da wir jetzt eh d'accord sind, was die gekürzte Version anbelangt, gibts eh nix zu streiten :-)		::Aber da wir jetzt eh d'accord sind, was die gekürzte Version anbelangt, gibts eh nix zu streiten :-) --[[Benutzer:Sebastian.Dietrich\|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich\|<big>✉</big>]] 12:45, 20. Feb. 2020 (CET)
	--[[Benutzer:Sebastian.Dietrich\|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich\|<big>✉</big>]] 12:45, 20. Feb. 2020 (CET)

Sebastian.Dietrich: /* Portabler Quellcode */

2020-02-20T11:48:50Z

Portabler Quellcode

← Nächstältere Version		Version vom 20. Februar 2020, 13:48 Uhr
Zeile 49:		Zeile 49:
	:: Die C standard library ist nicht dasselbe - das ist eine Library, die für viele Plattformen verfügbar ist. Ein ausschließlich mit der libc gelinktes C-Programm ist deshalb nicht portabel, es muss erst für die jeweilige Plattform compiliert werden. Wenn ich also mysql für Windows runterlade, dann wird es nicht auf einem Mac laufen - also ist MySQL nicht portabel, auch wenn es für viele Betriebssysteme Downloads gibt		:: Die C standard library ist nicht dasselbe - das ist eine Library, die für viele Plattformen verfügbar ist. Ein ausschließlich mit der libc gelinktes C-Programm ist deshalb nicht portabel, es muss erst für die jeweilige Plattform compiliert werden. Wenn ich also mysql für Windows runterlade, dann wird es nicht auf einem Mac laufen - also ist MySQL nicht portabel, auch wenn es für viele Betriebssysteme Downloads gibt
	::@Java ist langsamer - das stimmte noch im Jahr 2000, ist aber inzwischen schon lange nicht mehr so. Die korrekte Antwort auf "Ist Java langsamer als C oder C++" ist "es kommt darauf an". Der Grund dafür ist, das all die Performanceoptimierungen, die es in C/C++ gibt rein statischer Natur sind. In Java (oder C# etc.) kann zur Laufzeit weitaus mehr bestimmt werden, was optimiert wird. z.B. machen GarbageCollectoren Speicher-Defragmentierung, wodurch kürzere Sprünge und Pointer möglich sind. Oder loop-unfolding, wenn bei einer Schleife zur Laufzeit nur wenige Iterationen nötig sind. Bei trivialen Microbenchmarks bringt sowas noch recht wenig, dennoch gabs schon 2003 Untersuchungen, bei denen sogar bei Microbenchmarks Java besser als C++ abschnitt (siehe z.B. https://shop.heise.de/katalog/daniel-dusentrieb oder http://scribblethink.org/Computer/javaCbenchmark.html). Und seit 2003 hat sich Java gerade hinsichtlich Performance noch deutlich gesteigert. C/C++ hat sicherlich seine Daseinsberechtigung bei hardwarenaher Programmierung wie z.B. embedded devices - da wird es auch performanter sein, aber ansonsten und insbesondere bei großen Applikationen ist man (auch) hinsichtlich Performance mit Java mit höchster Wahrscheinlichkeit besser dran.		::@Java ist langsamer - das stimmte noch im Jahr 2000, ist aber inzwischen schon lange nicht mehr so. Die korrekte Antwort auf "Ist Java langsamer als C oder C++" ist "es kommt darauf an". Der Grund dafür ist, das all die Performanceoptimierungen, die es in C/C++ gibt rein statischer Natur sind. In Java (oder C# etc.) kann zur Laufzeit weitaus mehr bestimmt werden, was optimiert wird. z.B. machen GarbageCollectoren Speicher-Defragmentierung, wodurch kürzere Sprünge und Pointer möglich sind. Oder loop-unfolding, wenn bei einer Schleife zur Laufzeit nur wenige Iterationen nötig sind. Bei trivialen Microbenchmarks bringt sowas noch recht wenig, dennoch gabs schon 2003 Untersuchungen, bei denen sogar bei Microbenchmarks Java besser als C++ abschnitt (siehe z.B. https://shop.heise.de/katalog/daniel-dusentrieb oder http://scribblethink.org/Computer/javaCbenchmark.html). Und seit 2003 hat sich Java gerade hinsichtlich Performance noch deutlich gesteigert. C/C++ hat sicherlich seine Daseinsberechtigung bei hardwarenaher Programmierung wie z.B. embedded devices - da wird es auch performanter sein, aber ansonsten und insbesondere bei großen Applikationen ist man (auch) hinsichtlich Performance mit Java mit höchster Wahrscheinlichkeit besser dran.
	::Will darüber aber jetzt nicht streiten (da gab es immer schon Glaubenskriege). Beweisen lassen sich nur Performanceaussagen zu Microbenchmarks - auch das ist wesentlich komplexer als man annehmen könnte (auf Grund des "in die Gänge kommen" des Hot-Spot Compilers bei Java), lässt aber darüberhinaus keine Aussage zu Real-World Applikationen zu (wo die Performance meist nicht im Code, sondern in der DB oder der unpassenden Architektur verloren geht) --[[Benutzer:Sebastian.Dietrich\|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich\|<big>✉</big>]] 12:45, 20. Feb. 2020 (CET)		::Will darüber aber jetzt nicht streiten (da gab es immer schon Glaubenskriege). Beweisen lassen sich nur Performanceaussagen zu Microbenchmarks - auch das ist wesentlich komplexer als man annehmen könnte (auf Grund des "in die Gänge kommen" des Hot-Spot Compilers bei Java), lässt aber darüberhinaus keine Aussage zu Real-World Applikationen zu (wo die Performance meist nicht im Code, sondern in der DB oder der unpassenden Architektur verloren geht)
			::Aber da wir jetzt eh d'accord sind, was die gekürzte Version anbelangt, gibts eh nix zu streiten :-)
			--[[Benutzer:Sebastian.Dietrich\|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich\|<big>✉</big>]] 12:45, 20. Feb. 2020 (CET)

Sebastian.Dietrich: /* Portabler Quellcode */

2020-02-20T11:46:21Z

Portabler Quellcode

← Nächstältere Version		Version vom 20. Februar 2020, 13:46 Uhr
Zeile 44:		Zeile 44:
	: Java ist aus technischen Gründen übrigens langsamer als C oder C++, wenn man die statistische Verteilung anschaut. Bei Java wird jedes Objekt (Reference Type) auf dem dynamischen Heap abgelegt, das vom Garbage Collector getraced werden muss. In C++ hat man die Möglichkeit, Objekte mit "unique_ptr" GC-frei auf dem Heap oder auf dem Function-Call-Stack abzulegen (RAII). Außerdem muss in der JVM jeder referentielle Funktionsparameter vom GC getraced werden, da es in Java kein Mechanismus gibt, der manchmal als "Borrowed Reference" bezeichnet wird. In C, C++ oder Rust gibt es das. Außerdem kann man in C, C++ oder Rust aggressiver "Inlining" betreiben. In Java ist jede nicht-statische Methode "virtual" und wird erst zur Laufzeit ermittelt. Dadurch können C oder C++ Programme potenziell den Cache effizienter nutzen. --[[Benutzer:Diaspomod\|Diaspomod]] ([[Benutzer Diskussion:Diaspomod\|Diskussion]]) 10:40, 20. Feb. 2020 (CET)		: Java ist aus technischen Gründen übrigens langsamer als C oder C++, wenn man die statistische Verteilung anschaut. Bei Java wird jedes Objekt (Reference Type) auf dem dynamischen Heap abgelegt, das vom Garbage Collector getraced werden muss. In C++ hat man die Möglichkeit, Objekte mit "unique_ptr" GC-frei auf dem Heap oder auf dem Function-Call-Stack abzulegen (RAII). Außerdem muss in der JVM jeder referentielle Funktionsparameter vom GC getraced werden, da es in Java kein Mechanismus gibt, der manchmal als "Borrowed Reference" bezeichnet wird. In C, C++ oder Rust gibt es das. Außerdem kann man in C, C++ oder Rust aggressiver "Inlining" betreiben. In Java ist jede nicht-statische Methode "virtual" und wird erst zur Laufzeit ermittelt. Dadurch können C oder C++ Programme potenziell den Cache effizienter nutzen. --[[Benutzer:Diaspomod\|Diaspomod]] ([[Benutzer Diskussion:Diaspomod\|Diskussion]]) 10:40, 20. Feb. 2020 (CET)

	::Hi ~~Diapomod~~! Kannst ruhig du sagen - in der WP sind alle per Du.		::Hi Diaspomod! Kannst ruhig du sagen - in der WP sind alle per Du.
	::@Begriff "Portabilität" - da bin ich ganz bei dir. Es geht nur um die Ausführbarkeit. Darum fand ich "der Quellcode ist portabel" so schrecklich, weil Quellcode nicht ausführbar ist (zumindest nicht bei compilierten Sprachen) und somit nicht "portabel" im Sinne "run everywhere" sein kann.		::@Begriff "Portabilität" - da bin ich ganz bei dir. Es geht nur um die Ausführbarkeit. Darum fand ich "der Quellcode ist portabel" so schrecklich, weil Quellcode nicht ausführbar ist (zumindest nicht bei compilierten Sprachen) und somit nicht "portabel" im Sinne "run everywhere" sein kann.
	::@Softwarebibliotheken - da bin ich nicht deiner Meinung: JDK ist das developer-kit und nicht portabel (du musst das JDK bzw. die JRE extra für deine Plattform runterladen). Was du meinst sind Java Programme (JARs, WARs, EARs) - die laufen ohne neu compiliert zu werden auf unterschiedlichen Betriebssystemen (da das compilat = Bytecode auf den jeweiligen JREs interpretiert/jit-compiliert/etc wird). Nur wenn man (was niemand wirklich macht) in Java mittels JNI auf C/C++ zugreift oder sonstige unübliche Dinge macht, dann sind Java Programme nicht portabel.		::@Softwarebibliotheken - da bin ich nicht deiner Meinung: JDK ist das developer-kit und nicht portabel (du musst das JDK bzw. die JRE extra für deine Plattform runterladen). Was du meinst sind Java Programme (JARs, WARs, EARs) - die laufen ohne neu compiliert zu werden auf unterschiedlichen Betriebssystemen (da das compilat = Bytecode auf den jeweiligen JREs interpretiert/jit-compiliert/etc wird). Nur wenn man (was niemand wirklich macht) in Java mittels JNI auf C/C++ zugreift oder sonstige unübliche Dinge macht, dann sind Java Programme nicht portabel.

← Nächstältere Version		Version vom 4. Juli 2023, 14:23 Uhr
Zeile 22:		Zeile 22:
	:Youtubevideo mit Widenius-Interview als Einzelnachweis für die Aussprache im Artikel ergänzt. Also Aussprache "mai". --[[Benutzer:--\|--]] ([[Benutzer Diskussion:--\|Diskussion]]) 13:24, 16. Nov. 2016 (CET)		:Youtubevideo mit Widenius-Interview als Einzelnachweis für die Aussprache im Artikel ergänzt. Also Aussprache "mai". --[[Benutzer:--\|--]] ([[Benutzer Diskussion:--\|Diskussion]]) 13:24, 16. Nov. 2016 (CET)
	:ja das dachte ich auch. --[[Benutzer:Binbesser\|Binbesser]] ([[Benutzer Diskussion:Binbesser\|Diskussion]]) 14:22, 4. Jul. 2023 (CEST)		:ja das dachte ich auch. --[[Benutzer:Binbesser\|Binbesser]] ([[Benutzer Diskussion:Binbesser\|Diskussion]]) 14:22, 4. Jul. 2023 (CEST)
			::oder gleich letter by letter: em, why, es, kyu, el. --[[Benutzer:Binbesser\|Binbesser]] ([[Benutzer Diskussion:Binbesser\|Diskussion]]) 14:23, 4. Jul. 2023 (CEST)
	{{erledigt\|1=[[Spezial:Beiträge/87.123.4.206\|87.123.4.206]] 12:15, 24. Nov. 2016 (CET)}}		{{erledigt\|1=[[Spezial:Beiträge/87.123.4.206\|87.123.4.206]] 12:15, 24. Nov. 2016 (CET)}}

← Nächstältere Version		Version vom 4. Juli 2023, 14:22 Uhr
Zeile 21:		Zeile 21:
	:Wie man den Vornamen ausspricht, weiß ich nicht. Selbst wenn der "Mü" ausgesprochen werden sollte, ist das bei "MySQL" anders. Über die Gründe können wir jetzt viel mutmaßen, was den Artikel ohne reputable Quelle nicht weiterbringt. Meine persönliche Theoriefindung ist, dass der Begriff deshalb "My" wie "mein" ausgesprochen wird, weil er im Englischen benutzt und "my" dort nunmal so ausgesprochen wird. --[[Spezial:Beiträge/87.123.26.109\|87.123.26.109]] 16:20, 22. Okt. 2016 (CEST)		:Wie man den Vornamen ausspricht, weiß ich nicht. Selbst wenn der "Mü" ausgesprochen werden sollte, ist das bei "MySQL" anders. Über die Gründe können wir jetzt viel mutmaßen, was den Artikel ohne reputable Quelle nicht weiterbringt. Meine persönliche Theoriefindung ist, dass der Begriff deshalb "My" wie "mein" ausgesprochen wird, weil er im Englischen benutzt und "my" dort nunmal so ausgesprochen wird. --[[Spezial:Beiträge/87.123.26.109\|87.123.26.109]] 16:20, 22. Okt. 2016 (CEST)
	:Youtubevideo mit Widenius-Interview als Einzelnachweis für die Aussprache im Artikel ergänzt. Also Aussprache "mai". --[[Benutzer:--\|--]] ([[Benutzer Diskussion:--\|Diskussion]]) 13:24, 16. Nov. 2016 (CET)		:Youtubevideo mit Widenius-Interview als Einzelnachweis für die Aussprache im Artikel ergänzt. Also Aussprache "mai". --[[Benutzer:--\|--]] ([[Benutzer Diskussion:--\|Diskussion]]) 13:24, 16. Nov. 2016 (CET)
			:ja das dachte ich auch. --[[Benutzer:Binbesser\|Binbesser]] ([[Benutzer Diskussion:Binbesser\|Diskussion]]) 14:22, 4. Jul. 2023 (CEST)
	{{erledigt\|1=[[Spezial:Beiträge/87.123.4.206\|87.123.4.206]] 12:15, 24. Nov. 2016 (CET)}}		{{erledigt\|1=[[Spezial:Beiträge/87.123.4.206\|87.123.4.206]] 12:15, 24. Nov. 2016 (CET)}}

← Nächstältere Version		Version vom 1. März 2020, 01:25 Uhr
Zeile 3:		Zeile 3:
	{{Autoarchiv\|Alter=100\|Frequenz=monatlich\|Mindestabschnitte=3\|Ziel='((Lemma))/Archiv'\|Mindestbeiträge=1}}		{{Autoarchiv\|Alter=100\|Frequenz=monatlich\|Mindestabschnitte=3\|Ziel='((Lemma))/Archiv'\|Mindestbeiträge=1}}
	{{Redundanzhinweis\|3=MySQL Cluster\|4=MySQL#Cluster-Technik\|Beginn=März 2008\|Ende=Juni 2008\|Diskussion=Wikipedia:Redundanz/März 2008#MySQL Cluster - MySQL#Cluster-Technik (erledigt)}}		{{Redundanzhinweis\|3=MySQL Cluster\|4=MySQL#Cluster-Technik\|Beginn=März 2008\|Ende=Juni 2008\|Diskussion=Wikipedia:Redundanz/März 2008#MySQL Cluster - MySQL#Cluster-Technik (erledigt)}}

	== Quellen veraltet ==

	Die Quelle http://www.mysql.de/why-mysql/marketshare/ war veraltet (404) - habe sie bis auf Weiteres aus den Quellen gelöscht. Ist die genannte Seite evtl. nur umgezogen? Weiß jemand was darüber? --[[Spezial:Beiträge/2A02:8109:83C0:1959:6DCF:B3E9:6365:5BC1\|2A02:8109:83C0:1959:6DCF:B3E9:6365:5BC1]] 21:36, 8. Feb. 2015 (CET)

	== {{Anker\|deadurl_2015-10}} Defekte Weblinks ==		== {{Anker\|deadurl_2015-10}} Defekte Weblinks ==