Performanceprobleme D7 unter Windows Server 2003 64-bit

[erasmus]

hi,
ich habe vor kurzen D7 Enterprise auf einem Windows Server 2003 64-bit installiert, dachte so könnte ich volle 8 GB für die Kompilierung benutzen.
Die IDE läuft so weit problemlos. Allerdings habe ich festgestellt dass die Kompilierung sehr viel langsamer abläuft als auf einem älteren PC mit nur 1 GB jedoch Windows 2003 Standard 32-bit.
Prozessor- und Ram-Auslastung ist nahezu 0, trotzdem ist es saulangsam.
Hat jemand eine Idee voran das liegen könnte ?

Grüße
Erasmus

[Muetze1]

Zitat:

Zitat von erasmus

..., dachte so könnte ich volle 8 GB für die Kompilierung benutzen.

Wie kommst du denn auf diese Idee? Es ist eine 32 Bit App mit 32 Bit Code und 32 Bit Pointern und einem 32 Bit Speichermanager, welche die 32 Bit WinAPI nutzt (also die emulierte WinAPI) - wie kommst du also darauf das die Applikation diesen Speicher nutzen könnte?

Weil wenn diese Frage geklärt wird, lohnt es sich wohl nicht mehr das Problem zu lösen bzw. weiter auf dem OS zu forschen...

[RavenIV]

Meiner Meinung nach bringen die 64-Bit-Betriebssysteme nur etwas, wenn auch alle verwendeten Programme 64-Bit sind.

Kurzes dummes Beispiel:
Was nutzt mir ein Ferrari, der 250 km/h läuft, wenn ich Winterreifen habe, mit denen ich nur 120 km/h fahren kann?
Und was soll ich mit dem heissen Auto, wenn ich nur in der Stadt rumfahre und nur maximal 50 km/h fahren darf?

[mkinzler]

Zitat:

Meiner Meinung nach bringen die 64-Bit-Betriebssysteme nur etwas, wenn auch alle verwendeten Programme 64-Bit sind.

Wenn eine Anwendung, die man oft verwendet, von 64Bit profitiert sollte das doch reichen. Oder?
Ein weiterer Vorteil ist z.B. die Möglichkeit mehr Speicher zu verwenden.

[RavenIV]

Zitat:

Zitat von mkinzler

Zitat:

Meiner Meinung nach bringen die 64-Bit-Betriebssysteme nur etwas, wenn auch alle verwendeten Programme 64-Bit sind.

Wenn eine Anwendung, die man oft verwendet, von 64Bit profitiert sollte das doch reichen. Oder?

Dann müsste das aber schon eine 64-Bit Anwendung sein, oder?
Von was könnte eine 32-Bit oder 16-Bit Anwendung profitieren?

Zitat:

Zitat von mkinzler

Ein weiterer Vorteil ist z.B. die Möglichkeit mehr Speicher zu verwenden.

Man kann den Speicher insgesamt verwenden.
Aber jede Applikation für sich kann nicht auf den gesamten Speicher zugreifen.
Und für eine normale Arbeitsstation reichen doch wohl 4 GB Arbeitsspeicher aus, oder nicht?

[mkinzler]

Zitat:

Und für eine normale Arbeitsstation reichen doch wohl 4 GB Arbeitsspeicher aus, oder nicht?

Unter Windows aber nur 3
Es kommt auf die Anwendung(en) an. Im allgemeinen ist mehr immer besser.

Zitat:

Dann müsste das aber schon eine 64-Bit Anwendung sein, oder?

Natürlich. Du hast aber von allen Programmen gesprochen und ich meinte, das ein wichtiges Programm eigentlich schon ausreicht.

[Muetze1]

Zitat:

Zitat von RavenIV

Von was könnte eine 32-Bit oder 16-Bit Anwendung profitieren?

Microsoft hat keinen Support mehr für 16 Bit Teile. Diese werden komplett gar nicht mehr unterstützt.

(Diese Aussage bezieht sich nur auf auf die 64 Bit Windows Betriebssysmversionen von Microsoft. Also auch nicht auf das Linux von Microsoft!)

[erasmus]

Hallo da bin ich nochmal:

zum Speicher: ich habe nicht erwähnt, dass auf diesem Server mehrere Programmierer gleichzeitig via Terminal arbeiten sollen und dann bringen die 8 GB schon was, weil die dann auf die verschiedenen Sessions aufgeteilt werden. auf diese weise hat jeder für die Kompilierung seine 2-3 GB zur verfügung.

aber anyway das war nicht meine Frage !

mein Problem ist die generelle Performance von Delphi unter diesem Betriebsystem. Während andere Programm normal zu laufen scheinen, braucht Delphi für´s compilieren + linken ewig lange.
vor an könnte das eurer Meinung nach liegen ?

[RavenIV]

Zitat:

Zitat von erasmus

...auf diesem Server mehrere Programmierer gleichzeitig via Terminal arbeiten...
...
mein Problem ist die generelle Performance von Delphi unter diesem Betriebsystem. Während andere Programm normal zu laufen scheinen, braucht Delphi für´s compilieren + linken ewig lange.
vor an könnte das eurer Meinung nach liegen ?

Bist Du in einer Terminal-Session oder direkt am PC?

[mkinzler]

Auf einem (Terminal-)Server macht 64Bit und Multicore definitiv Sinn.

[Bernhard Geyer]

Zitat:

Zitat von erasmus

mein Problem ist die generelle Performance von Delphi unter diesem Betriebsystem. Während andere Programm normal zu laufen scheinen, braucht Delphi für´s compilieren + linken ewig lange.
vor an könnte das eurer Meinung nach liegen ?

Schau mal auf den Taskmanager. Ich vermute mal das nicht Delphi das grunsätzliche Problem ist sondern das das BS einfach nicht schnell genug liefert bzw. beim Datei-Suchen irgendwelche Verlangsamungen vorhanden sind.

[erasmus]

[quote="RavenIV"]

Zitat:

Zitat von erasmus

Bist Du in einer Terminal-Session oder direkt am PC?

habe beides probiert, kein unterschied.
auch der Taskmanager sagt nichts. CPU+ Speicher bleiben während Kompilierung nahe 0.

[Bernhard Geyer]

Zitat:

Zitat von erasmus

auch der Taskmanager sagt nichts. CPU+ Speicher bleiben während Kompilierung nahe 0.

Das würde bestätigen das die Festplatte das bremsende Element ist.

[franktron]

Also 64-Bit Windows bringt mit einer 32-Bit Anwendung garnix, aber mit mehreren gleichzeitig eine menge.

Und das Delphi mit Win 64 langsamer als mit Win 32 ist kann sein vor allem bei Win 2003 bei XP 64 geht das
Dual Core oder Dual Prozessor sind auch so ein Ding je nach Delphi Version läuft Delphi nur auf einem Core

[DGL-luke]

Hm, gibt es nicht ein Tool von Microsoft, mit dem man RAMDisks erstellen und ins dateisystem mounten kann (hab das mal im Zusammenhang mit Kiosksystemen / Verwendung von Flash-Speicher gelesen, glaube ich, das ist ne Kombination aus Treiber und CLI-Programm, soweit ich mich erinnern kann :-| )? Dorthin (1 GB sollte ja reichen, die übrigen 7GB reichen dann immer noch für 7-14 Delphi-Instanzen, schätz ich mal) müsste man dann das Projekt und die Libs verschieben. Wenn sich dann ein entsprechender leistungsschub ergibt, wissen wir, dass es an der Festplatte lag...

@franktron: Ja, genau darum gehts, mehrere Delphis auf einem Server ;-)