Wie viel Aufwand, um für mehrere OS zu entwicklen?

Steffo schrieb:

Ist das für eine IDE langsam?

Für einen Dateimanager ist es das und der war hier unser Thema.

Das starten des TV Browser dauert hier bei mir unter Ubuntu 64 Bit mit der JVM von Sun (Java 7) 16 Sekunden, das wäre für einen Dateimanager zu lange.

hustbaer

12 sec ist laaannge schrieb:

Steffo schrieb:

Es gibt Gegenbeispiele, wie du siehst...

Das soll ein positives Beispiel sein?

Überträgt man 12 Sekunden auf den Dateimanager, dann sind das 11 Sekunden zu viel!

Also 11 mal langsamer, als gefordert.
Oder, eine Verlangsamung um 1100 %.

Du bist recht grosszügig.
Mich nervt's schon wenn ein File-Manager 1 Sekunde braucht um zu starten.
Explorer startet quasi instant.

Natürlich... wenn das Ding richtig viel kann und super-mega-praktisch ist, dann warte ich gern 1 Sekunde.

Andres Beispiel. Ich verwende unter Windows dnGREP. Das braucht unter Windows 2-3 Sekunden zum Hochstarten. Gott weiss warum. Für meinen Geschmack sind die 3 Sekunden 2,75 Sekunden zu viel. Ich erdulde es aber, weil das Ding halt praktisch ist.

hustbaer schrieb:

Andres Beispiel. Ich verwende unter Windows dnGREP. Das braucht unter Windows 2-3 Sekunden zum Hochstarten. Gott weiss warum.

Auf der Webseite steht schon im ersten Satz:

.NET implementation of GREP tool with GUI.

Ich Tippe darauf, daß irgendwas von .Net nachgeladen werden muß.

Würde das Programm auf der WinAPI basieren, dann wäre es bestimmt instant da.

Würde das Programm auf der WinAPI basieren, dann wäre es bestimmt instant da.

Solche pauschalen Aussagen stimmen doch nicht. Bei mir startet VS 2012, welches große .Net Teile besitzt (allem vor ran die WPF GUI), in unter 3 Sekunden. Und so ein Programm ist wesentlich komplexer als irgend ein Grep Tool.

Bei großen Programmen (damit meine ich jetzt wirklich umfangreich an zu ladenen Code, ne Menge Dlls müssen von Platte geladen werden etc.) wie z.B. VS ist sowieso die Festplatte das begrenzende Medium. Genauso bei Dateimanagern - die bekommt man schnell wenn man halt asynchron nur die Dateipfade durchgeht, die der User wirklich sieht - klingt selbstverständlich, aber hab schon zu viele Versuche gesehen die massig Zeit benötigen und User warten lassen, nur aufgrund von viel IO Zugriffen.

Zwergli schrieb:

Würde das Programm auf der WinAPI basieren, dann wäre es bestimmt instant da.

Solche pauschalen Aussagen stimmen doch nicht. Bei mir startet VS 2012, welches große .Net Teile besitzt (allem vor ran die WPF GUI), in unter 3 Sekunden. Und so ein Programm ist wesentlich komplexer als irgend ein Grep Tool.

Ich würde eher darauf wetten, daß Microsoft als Eigentümer von Windows und VS so schlau ist, die Ladezeit wichtiger Komponenten in die Bootzeit des OS zu stecken, damit man hinterher, wenn man VS startet, davon nichts mehr merkt.

Insofern ist VS ein schlechtes Beispiel.

Bei großen Programmen (damit meine ich jetzt wirklich umfangreich an zu ladenen Code, ne Menge Dlls müssen von Platte geladen werden etc.) wie z.B. VS ist sowieso die Festplatte das begrenzende Medium.

Mein Lieblings Torrent Client ist uTorrent, der ist nämlich nur 1 MB groß.
Ein guter und von vielen empfohlener crossplattform fähiger Open Source Torrent Client, den ich mal getestet habe, hatte die gleichen Fähigkeiten wie der uTorrent Client, aber er kam mit sage und schreibe 70 MB HD Speicherverbrauch, entsprechend mies waren dann auch seine Startzeiten.

uTorrent ist dagegen ein winapi Programm und die Startzeiten sind so super, daß er instant da ist.
Er ist zwar nicht Open Source, sondern nur Freeware aber die Programmgröße, sein Speicherverbrauch und super startzeiten sind für mich ein Grund ihn klar zu bevorzugen.

Gut, ein Torrent Client ist jetzt nicht unbedingt ein Programm, das man häufig startet und wieder beendet, zeigt aber dennoch die Zusammenhänge auf, zwischen den Ladezeiten und dem zu ladenden API Ballast.

Insofern ist VS ein schlechtes Beispiel.

Nur wenn deine Behauptung, die du ohne Verweis auf eine Quelle als gegeben darstellst, wahr wäre...

Wieso sollte man Teile eines solchen Programms spekulativ vorladen und damit Speicher und Rechenzeit verbrauchen, wenn das Programm wahrscheinlich nur in einem Bruchteil der Startvorgänge, danach wirklich genutzt werden sollte?

µTorrent ist sicherlich ein gutes Beispiel für ein schnell ladendes Programm, aber von der Komplexität kommt es nicht mal ansatzweise in die Nähe von Software wie VS.

hustbaer

12 sec ist laaannge schrieb:

Ich Tippe darauf, daß irgendwas von .Net nachgeladen werden muß.

Laden ist nicht das Problem, die 2-3 Sek. haste auch mit SSD und beim 2. mal Starten in unmittelbarer Folge.
Das JITen kann eigentlich auch nicht das Problem sein, das sollte auch nur beim 1. Mal Starten gemacht werden.
Bleibt die Initialisierung von irgendwelchem Scheissendreck. K.a. was bei manchen .NET Programmen da so bremst.

Aber egal, ich wollte lediglich ein Beispiel bringen dafür was ich noch für OK halte und was nichtmehr.

Und dass mir eben 1 Sekunde schon zu lange ist. Vor allem wenn man - weil man eben so ungeduldig ist - ein bisschen Geld in die Hand nimmt und sich nen dicken i7 kauft. Wenns auf der stärksten für nicht-bekloppt-viel Geld verfügbaren CPU immer noch 2-3 Sekunden sind, dann läuft mMn. irgendwas falsch.

der native filemanager ist natürlich ins os integriert. dementsprechend startet der quasi instant. der windows filemanager ist ja fest ins fenstermanagement integriert.

natürlich startet eine jvm langsamer als ein bereits durchs OS geladenes tool. nuff said.

kA was ihr für kisten habt, aber meine wenigen java anwendungen mit gui starten nicht merkbar langsamer als die nativen konkurrenz produkte. bei mir ist das vor allem Intellij IDEA und DBVisualizer.

die plattformunabhängigkeit ist mir hier tausend mal wichtiger als jede startup time. denn ich kann diese tools benutzen unabhängig vom OS. fände es schrecklich, wenn meine entwicklungswerkzeuge mir das OS aufzwingen würden. habe früher windows benutzt, heute nur noch mac osx und ubuntu. die wichtigsten tools sind gleich geblieben dank plattformunabhängigkeit.

und was bringt euch nun die achso schnelle startup time? beeilt ihr euch morgens dann extra beim kaffeeholen, damit ihr schneller losarbeiten könnt?

hustbaer

lolhehe schrieb:

der native filemanager ist natürlich ins os integriert. dementsprechend startet der quasi instant. der windows filemanager ist ja fest ins fenstermanagement integriert.

Ist doch egal wieso das so ist, darum gings ja nicht. Ich wollte lediglich meine Meinung zum Thema "was ist schnell" äussern (=was empfinde ich als "angenehm schnell").
Und dabei ist eben vollkommen egal warum was so lange braucht wie es braucht.

natürlich startet eine jvm langsamer als ein bereits durchs OS geladenes tool. nuff said.

Schneller/langsamer, alles uninteressant. So lange es unter 0,25 Sek. braucht ist mir egal welches Tool nun schneller ist. Sogar bei unter 0,5 Sek. ist es mir noch egal. Ab 1 Sekunde fängt es an zu nerven.

blub blubblub blub blubblubblubblub

blaaaaaaah

Zwergli schrieb:

Insofern ist VS ein schlechtes Beispiel.

Nur wenn deine Behauptung, die du ohne Verweis auf eine Quelle als gegeben darstellst, wahr wäre...

Wieso sollte man Teile eines solchen Programms spekulativ vorladen und damit Speicher und Rechenzeit verbrauchen,

.Net wird sicher vorgeladen, weil es inzwischen gehäuft von verschiedenen Anwendungen unter Windows benutzt wird und ich merke es auch an der langsamer gewordenen Startzeit meines Windows, nachdem ich VS installiert habe.

hustbaer schrieb:

lolhehe schrieb:

der native filemanager ist natürlich ins os integriert. dementsprechend startet der quasi instant. der windows filemanager ist ja fest ins fenstermanagement integriert.

Ist doch egal wieso das so ist, darum gings ja nicht. Ich wollte lediglich meine Meinung zum Thema "was ist schnell" äussern (=was empfinde ich als "angenehm schnell").
Und dabei ist eben vollkommen egal warum was so lange braucht wie es braucht.

natürlich startet eine jvm langsamer als ein bereits durchs OS geladenes tool. nuff said.

Schneller/langsamer, alles uninteressant. So lange es unter 0,25 Sek. braucht ist mir egal welches Tool nun schneller ist. Sogar bei unter 0,5 Sek. ist es mir noch egal. Ab 1 Sekunde fängt es an zu nerven.

warum? jetzt sag bitte nicht, dass du programme jedes mal beendest, wenn du sie grade mal nicht brauchst.

hab ne ssd und 8gb ram. klicke mich morgens instant durchs dock, nach 10sec sind alle programme geladen und bleiben für den rest des tages offen. ab dann wird nur noch mit alt tab geswitcht. die startup time der programme ist mir echt sowas von egal. die hauptsache ist, sie sind schnell wenn sie geöffnet sind.

12 sec ist laaannge schrieb:

.Net wird sicher vorgeladen, weil es inzwischen gehäuft von verschiedenen Anwendungen unter Windows benutzt wird und ich merke es auch an der langsamer gewordenen Startzeit meines Windows, nachdem ich VS installiert habe.

Dann wirds ja aus gutem Grund geladen, einfach weils benötigt wird von irgendwelchen Programmen. Windows an sich lädt das nicht automatisch. Wenn du .Net irgendwie ankreiden möchtest, das es überhaupt geladen werden muss bei der ersten Benutzung, vergiss nicht das es bei C und C++ Programmen genauso ist. Es gibt auch ne C Runtime und ne Visual C++ Runtime die geladen werden müssen (was sogar richtig ätzend ist da, zig Versionen parallel geladen werden müssen). Das geschieht auch meistens beim Start, weil halt Windows auch viele davon brauch.

Und VS verlangsamt den Windows Start in keinster Weise. Wenn du es nicht startest, wird auch nichts geladen. Was aber den Start potentiell verlangsamen kann, ist andere Software die standardmäßig mitinstalliert wird mit dem VS, wie z.B. der SQL Server Express. Aber das ist nicht VS.

Ist mir auch ein Rätsel, was die Leute hier dauernd Programme am starten und beenden sind. Seid ihr die selben die sich über Windows 8 "Singletasking" beschweren?

Ansonsten kann ich nur beitragen, dass VS 2010 Ultimate bei mir furchtbar langsam startet, bestimmt 10 sek. Und danach sind noch nichtmal die Projekte geladen, das muss ich erst noch manuell anklicken und dann nochmal einige Sekunden warten bis alle Fenster wiederhergestellt sind. Und ich hab nun wirklich keinen langsamen Rechner (aber keine ssd)

hustbaer

VS 2010 ist fies.
Wobei es Installationen gibt die sehr schnell starten (max. 1-2 Sekunden), andere auf gleicher Hardware brauchen so um die 10 Sek. oder mehr. Beim 2. mal Starten!
Vermutlich ist irgendeine Komponente schuld die man optional mit installieren kann. Bloss weiss ich nicht welche

Zwergli schrieb:

12 sec ist laaannge schrieb:

.Net wird sicher vorgeladen, weil es inzwischen gehäuft von verschiedenen Anwendungen unter Windows benutzt wird und ich merke es auch an der langsamer gewordenen Startzeit meines Windows, nachdem ich VS installiert habe.

Dann wirds ja aus gutem Grund geladen, einfach weils benötigt wird von irgendwelchen Programmen. Windows an sich lädt das nicht automatisch. Wenn du .Net irgendwie ankreiden möchtest, das es überhaupt geladen werden muss bei der ersten Benutzung, vergiss nicht das es bei C und C++ Programmen genauso ist. Es gibt auch ne C Runtime und ne Visual C++ Runtime die geladen werden müssen (was sogar richtig ätzend ist da, zig Versionen parallel geladen werden müssen). Das geschieht auch meistens beim Start, weil halt Windows auch viele davon brauch.

Ich habe ja gesagt, daß es einen Unterschied macht, wenn APIs zum OS Bestandteil (WinAPI, MFC und inzwischen wohl auch .NET)gehören oder extra noch geladen werden müssen (letztere gilt für GTK+, qt, JVM und viele weitere).

hustbaer

MFC und .NET gehören nicht zum OS. Sie werden nur mininstalliert.

MFC und .NET werden auch - wie jede andere DLL die nicht mit dem Kernel verheiratet ist - für jeden Prozess neu initialisiert. (Das trifft übrigens auf den überwiegenden Grossteil der DLLs in system32 zu, gibt nur ein paar wenige Ausnahmen ala GDI, KERNEL, USER)

Was CPU-Zeit beim Starten angeht sind diese also genau gleich zu sehen wie komplett unabhängige Libs/DLLs ala Boost, Qt, ...
Und die echten "Ladezeiten" (HDD Zugriffe) sind (mir persönlich) vollkommen egal, denn das sind bei mir SSD Zugriffe, und kaum spürbar.

BeispielL VS 2010 startet das 1. mal nach nem Reboot vielleicht 1-2 Sekunden langsamer als beim 2. Start wo schon alles im Cache steht -- bei geschätzten 20+ Sekunden die es CPU Zeit benötigt Fällt das nicht ins Gewicht.
Bei dnGREP ist es das selbe. Wie auch bei jedem anderen Programm das mich mit langen Startzeiten nervt.

Bei Rechnern ohne SSD sieht die Sache anders aus, aber darauf würde ich Anno 2012 nicht mehr optimieren. Die Zeit des Mitleids mit SSD-losen Usern ist vorbei

GPC

hustbaer schrieb:

Bei Rechnern ohne SSD sieht die Sache anders aus, aber darauf würde ich Anno 2012 nicht mehr optimieren. Die Zeit des Mitleids mit SSD-losen Usern ist vorbei

Also ich würde sagen, die große Mehrheit der PC User hat noch keine SSD. Insofern ist das schon eine Ansage, dass dir deren Startzeiten egal sind
Im Übrigen denke ich, dass auch hier im C++-Forum noch sehr viele ohne SSD arbeiten (inkl. mir).

hustbaer schrieb:

Bei Rechnern ohne SSD sieht die Sache anders aus, aber darauf würde ich Anno 2012 nicht mehr optimieren. Die Zeit des Mitleids mit SSD-losen Usern ist vorbei

Stell dir vor, die Entwickler würden nur noch SSD-Zeiten beachten, dann wären wir wieder schnell bei den Startzeiten angelangt, die man bei Festplatten hat...

Zeus

Steffo schrieb:

hustbaer schrieb:

Bei Rechnern ohne SSD sieht die Sache anders aus, aber darauf würde ich Anno 2012 nicht mehr optimieren. Die Zeit des Mitleids mit SSD-losen Usern ist vorbei

Stell dir vor, die Entwickler würden nur noch SSD-Zeiten beachten, dann wären wir wieder schnell bei den Startzeiten angelangt, die man bei Festplatten hat...

Ein Systemprogrammierer hat ihm schon gerettet