10.4 Sydney IDEFixpack kommt da noch was ?

[TurboMagic]

Zitat von win568:

Hi

Emba soll nicht über Tricks von Andi erfreut sein, sondern die Fehler ausbessern. Ohne seine Änderungen
läuft bei uns gar nichts mehr (23 Mio Locs). Die Stabilität von 10.4 ist eine Frechheit. Das neue beworbene
Codeinsight funkt überhaupt nicht. Ich verwende daher wieder unsere eigene Implementierung als Experts Erweiterung.
Nicht mal so einfache Geschichten wie Layout speichern funktioniert. Und wir müssen für dutzende Leute
ständig Lizenzen nachkaufen, für ein Produkt das immer schlechter wird.

Einen gewissen Frust kann ich verstenen, aber es wird ja inzwischen wieder aktiver an der IDE gearbeitet.
Jetzt ist 10.4.1 raus und da sind diverse Fixes für den LSP drin. Damit ist zwar noch nicht alles gut,
speziell aber bei größeren Projekten verhält er sich glaube ich ein recht gutes Stück besser!
Aber eine Aussage "funkt überhaupt nicht" ist so grobschlächtig nichtssagend, dass ich damit nichts anfangen kann.
Was genau geht nicht? Kommt keine Code Competion? Findet er Sachen nicht? Blockiert es die CPU...?

Und zum Fixpack: es geht hier nicht um "über Tricks erfreuen" sondern darum abzuschätzen welche der Dinge
die er mittels Fixpack gelöst hat sicher genug sind um diese zu übernehmen, was ja schon begonnen hat,
und welche man besser sein lässt, weil die doch zu viel Risiko beinhalten bei irgendjemand doch schief zu gehen.
Also nicht so einfach...

Ich hoffe auch, dass irgendwelche GetIt Probleme mit der neuen Patch Installationsmöglichkeit behoben sind, so
dass zeitnah weitere Dinge mittels Patch verbessert werden können!

[Borni]

Hallo zusammen,

die Compilerzeiten sind auch unter 10.4.1 nicht besser geworden. Oder gibt es noch einen anderen Trick ? (Compiler Speed Pack, IDE Package und Palette Cache)

Gruß Borni

[himitsu]

Multithreated im Hintergrund den Comandozeilen-Compiler ansteuern.

[Der Bastler]

Wir hoffen auch auf die Compilerbeschleunigung. Das ist für uns das k.o.-Kriterium für den Kauf neuer Delphi-Versionen.
Wir haben derzeit knapp 3 Mio. selbst geschriebener Code-Zeilen und noch einige Imports.
Im RIO mit IDEFixPack sind wir im Optimalfall bei reichlich 6min. Sydney braucht ca. 40 min. (Ist damit aber schneller als RIO ohne IDEFixPack)

Ein wichtiger Trick für das Optimum der Compilerzeiten liegt in der richtigen Reihenfolge der Units im USES. Wir haben hier ewig probiert und optimiert und haben über 30 Minuten rausgeholt.
Wir haben extra ein Tool geschrieben, dass uns die USES sortiert. Beim programmieren landen Neue i.d.R. nicht an der optimalen Stelle.
Evt. hilft Euch das weiter...

Viele Grüße, Lars

[woodie]

Zitat von Der Bastler:

Wir haben extra ein Tool geschrieben, dass uns die USES sortiert. Beim programmieren landen Neue i.d.R. nicht an der optimalen Stelle.

Was ist die optimale Reihenfolge für den Compiler? Wie findet eurer Tool das automatisch raus?

[dummzeuch]

Zitat von woodie:

Zitat von Der Bastler:

Wir haben extra ein Tool geschrieben, dass uns die USES sortiert. Beim programmieren landen Neue i.d.R. nicht an der optimalen Stelle.

Was ist die optimale Reihenfolge für den Compiler? Wie findet eurer Tool das automatisch raus?

Genau dies würde mich auch brennend interessieren.

[OlliWW]

Wahrscheinlich entscheidet das Tool nur ob es in der Implementatation oder im Interface landet. Sowas können aber meines Erachtens nach auch viele andere Tools bereits.

[freimatz]

Zitat von Der Bastler:

Ein wichtiger Trick für das Optimum der Compilerzeiten liegt in der richtigen Reihenfolge der Units im USES. Wir haben hier ewig probiert und optimiert und haben über 30 Minuten rausgeholt.
...
Evt. hilft Euch das weiter...

Viele Grüße, Lars

Danke. Noch mehr würde es helfen wenn Du uns verrätst, was denn die richtige Reihenfolge ist.

[himitsu]

Darum auch meine Empfehlung möglichst nur das USES im Interface zu benutzen.

Dort steht dir Reihenfolge fest, also immer in der Reihenfolge, wie es im Code steht.
* erste Unit
* dann das was in dieser Unit steht
* dann zweite Unit (falls nicht bereits in untergeordneten Units geladen)
* usw.

Das was im USES der Implementation steht, das kann der Compiler in beliebiger Reihenfolge einbinden.

Auch werden UNITs der Implementation eventuell erst nach dem Code der Initialization geladen und bereits vor der Finalization entladen,
während die UNITs im Interface immer vor Initialization geladen und erst nach Finalization entladen werden, womit deren Funktionen dort (sicher) nutzbar sind.
Selbes gilt für Codes der Class-Constructor und Class-Destructor.

[HeZa]

Zitat von himitsu:

Darum auch meine Empfehlung möglichst nur das USES im Interface zu benutzen.

Dort steht dir Reihenfolge fest, also immer in der Reihenfolge, wie es im Code steht.
* erste Unit
* dann das was in dieser Unit steht
* dann zweite Unit (falls nicht bereits in untergeordneten Units geladen)
* usw.

Das was im USES der Implementation steht, das kann der Compiler in beliebiger Reihenfolge einbinden.

wenn ich also die Units A, B und C habe und alle 3 den Bezeichner X definieren und ich in der implementation uses A, B, C angebe und X in meiner Unit verwende, dann verwende ich unter Umständen das X aus B oder A?

*Kopfkratz*