Stabilität des neuen Delphi X10 ?

[Peter Schütt]

Hallo,
anscheinend ist "non-tech" tot, deshalb wiederhole ich mein Posting hier:

wir verwenden XE7 und haben einige Millionen Zeilen Code in unserem größten Projekt.
In der IDE können wir das Projekt sowieso nicht compilieren, sondern es gibt dann einen OutOfMemory-Fehler. Der Speicherverbrauch liegt laut Taskmanager bei 1057 Mb.
32-Bit-Applikationen können aber bis 3500 Mb verbraten. Warum macht Delphi das nicht?

Richtig lustig ist die Werbung für XE10.

"Twice the IDE Memory capacity"

Anscheinend gibt es im Delphi-Code ein GetMem(IDEMemory, 1000000) und den hat bisher keiner gefunden, denn sonst wäre der Fehler ja nicht seit (gefühlt) Delphi 2009 drinnen und wurde bis XE7 nicht behoben, ja es wurde sogar immer schlimmer.

Nun haben wohl die IDE-Profis die Stelle gefunden und einer hat einfach mal 2000000 eingestellt und es ging irgendwie besser. Da sie aber nicht genau wissen, was dieser Wert wirklich macht, haben sie sich nicht getraut, ihn noch höher zu drehen.

Man kann mich naiv nennen: Ich würde erwarten, dass die IDE feststellt, wieviel Speicher vorhanden ist und den ausnutzt. Und ich würde auch erwarten, dass es schon seit Jahren eine 64-Bit-IDE gibt.
Und außerdem würde ich erwarten, dass es auch für XE7 einen Service-Pack gibt, der den Speicherfehler behebt. Wir mussten unserem Chef eine Menge Kohle für das Update von XE2 auf XE7 aus dem Etat leiern, in erster Linie dafür, dass die IDE noch öfter abstürzt als vorher.

Anfragen bei Embarcadero in Bezug auf diese Speicherfehler werden mit der kurzen knackigen Botschaft beantwortet: "Neue Version kaufen!"

Ciao
Peter Schütt

[Stefan M. Huber]

Post by Peter Schütt
Hallo,
wir verwenden XE7 und haben einige Millionen Zeilen Code in unserem größten Projekt.
In der IDE können wir das Projekt sowieso nicht compilieren, sondern es gibt dann einen OutOfMemory-Fehler. Der Speicherverbrauch liegt laut Taskmanager bei 1057 Mb.
32-Bit-Applikationen können aber bis 3500 Mb verbraten. Warum macht Delphi das nicht?

Hast du die DDevExtensions installiert und die Option
Compilation > [x] release compiler unit cache of other projects
before compiling
und
[x] release only if memory usage is high

aktiviert? Seit wir das bei uns haben, geht es problemlos und wir haben
nur 1 Projekt, das wir in XE7 kompilieren.

Wir haben allerdings auch nur 700MB Speicherfootprint beim Build.

Stefan

[Peter Schütt]

Hallo,
[..]

Post by Stefan M. Huber
Hast du die DDevExtensions installiert und die Option
Compilation > [x] release compiler unit cache of other projects
before compiling
und
[x] release only if memory usage is high
aktiviert? Seit wir das bei uns haben, geht es problemlos und wir haben
nur 1 Projekt, das wir in XE7 kompilieren.

Das hat bei uns leider nichts gebracht. Dafür ist unser Projekt wohl zu
groß.

Ciao
Peter Schütt

[Stefan M. Huber]

Post by Peter Schütt
Hallo,

Nachtrag: Das Usenet ist tot, nicht einzelne Gruppen :(

[Matthias Frey]

Post by Stefan M. Huber

Post by Peter Schütt
Hallo,

Nachtrag: Das Usenet ist tot, nicht einzelne Gruppen :(

Da ist man mal ein paar Tage weg ...

Matthias

[Hans-Peter Diettrich]

Post by Peter Schütt
Nun haben wohl die IDE-Profis die Stelle gefunden und einer hat
einfach mal 2000000 eingestellt und es ging irgendwie besser. Da sie
aber nicht genau wissen, was dieser Wert wirklich macht, haben sie
sich nicht getraut, ihn noch höher zu drehen.
Man kann mich naiv nennen: Ich würde erwarten, dass die IDE
feststellt, wieviel Speicher vorhanden ist und den ausnutzt.

Vorhandener und verfügbarer Speicher sind nicht gleichbedeutend. Wenn
DLLs oder Packages nachgeladen werden, brauchen die frischen Speicher,
der nicht bereits von der IDE reserviert wurde.

In 64 Bit Programmen sollte das kein Problem sein, bei 32 Bit ist der
Adressraum aber nur 4GB groß, wovon (ohne Tricks) nur 2GB frei verfügbar
sind. In allen Fällen ist es nicht ratsam, den ganzen freien Speicher zu
belegen, weil das ganz schnell zum Swappen führt. Zudem, was soll bei 64
Bit als "freier" Speicher betrachtet werden, der logische
Speicherbereich oder das physikalische RAM? Physikalisch ist in einem
guten Multitasking-System sowieso kein RAM frei, darum prügeln sich ja
alle aktuell laufenden Programme, und die Belegung des RAMs ändert sich
ständig, entsprechend den page-faults in den Programmen. Man kann davon
ausgehen, daß praktisch jederzeit ein Vielfaches des physikalischen RAMs
von Programmen reserviert ist, wovon nur die aktuell benötigten Seiten
tatsächlich im RAM liegen.

Post by Peter Schütt
Und ich
würde auch erwarten, dass es schon seit Jahren eine 64-Bit-IDE gibt.

Schon, aber das löst das Speicherproblem nicht wirklich. Man kann zwar
davon ausgehen, daß brauchbare Entwicklungsrechner über mindestens 4GB
RAM verfügen, aber da drin läuft neben den Anwendungsprogrammen auch
noch das System mit seinen Caches. Damit wird schon die Benutzung von
4GB für die IDE problematisch. Das Paging sorgt zwar dafür, daß nur
benutzte Seiten im Speicher liegen, doch kann die Anzahl dieser Seiten
durch Speicherfragmentierung (brutto) weit höher werden, als von der
reinen Speichernutzung (netto) zu erwarten wäre. Eine Komprimierung des
Speichers ist praktisch unmöglich, solange Pointer zum Sprachumfang
gehören, oder Referenz-Variablen für andere Daten verwendet werden
dürfen (oft TStrings.Objects[]).

Post by Peter Schütt
Und außerdem würde ich erwarten, dass es auch für XE7 einen
Service-Pack gibt, der den Speicherfehler behebt. Wir mussten unserem
Chef eine Menge Kohle für das Update von XE2 auf XE7 aus dem Etat
leiern, in erster Linie dafür, dass die IDE noch öfter abstürzt als
vorher.

Mir kommt die Entwicklung so vor wie bei open-source Projekten, bei
denen sich die Entwickler (kommerzielle auf Anweisung) mit neuen
Features beschäftigen, während die alten Fehler liegenbleiben, weil
bislang schon niemand Bock darauf hatte, sich damit zu befassen, und
weil bislang noch niemand eine Lösung gefunden hatte - sofern der
fehlerträchtige Code überhaupt irgendwie einzugrenzen ist.

Post by Peter Schütt
Anfragen bei Embarcadero in Bezug auf diese Speicherfehler werden mit
der kurzen knackigen Botschaft beantwortet: "Neue Version kaufen!"

Diesse Antwort sollte seit D7 eigentlich als bekannt vorausgesetzt
werden :-(

DoDi

[Matthias Frey]

Hallo,

Post by Hans-Peter Diettrich
Schon, aber das löst das Speicherproblem nicht wirklich. Man kann zwar
davon ausgehen, daß brauchbare Entwicklungsrechner über mindestens 4GB
RAM verfügen,

Brauchbar?

Brauchbare Entwicklungsrechner haben min 8 oder noch besser 16.
Ich würde wenn ich es einfach konfigurieren könnte 32 nehmen.

...

Post by Hans-Peter Diettrich

Post by Peter Schütt
Anfragen bei Embarcadero in Bezug auf diese Speicherfehler werden mit
der kurzen knackigen Botschaft beantwortet: "Neue Version kaufen!"

Diesse Antwort sollte seit D7 eigentlich als bekannt vorausgesetzt
werden :-(

Seit? War das nicht "nach" ;-)

Post by Hans-Peter Diettrich
DoDi

Matthias

[Matthias Frey]

Post by Peter Schütt
Hallo,

Hallo
Nein. Nur die Datenbank-Gruppe wurde abgeschafft.

Post by Peter Schütt
wir verwenden XE7 und haben einige Millionen Zeilen Code in unserem
größten Projekt. In der IDE können wir das Projekt sowieso nicht
compilieren, sondern es gibt dann einen OutOfMemory-Fehler. Der
Speicherverbrauch liegt laut Taskmanager bei 1057 Mb.
32-Bit-Applikationen können aber bis 3500 Mb verbraten. Warum macht Delphi das nicht?
...
Anfragen bei Embarcadero in Bezug auf diese Speicherfehler werden mit
der kurzen knackigen Botschaft beantwortet: "Neue Version kaufen!"

Tja

Post by Peter Schütt
Ciao Peter Schütt

Matthias

[Matthias Eißing]

Post by Peter Schütt
"Twice the IDE Memory capacity"

Und? Schon ausprobiert (mit der Trial von D10S)?

[Peter Schütt]

Hallo,

Post by Matthias Eißing

Post by Peter Schütt
"Twice the IDE Memory capacity"

Und? Schon ausprobiert (mit der Trial von D10S)?

Und? Wann kommt das Update von XE7, dass den Speicherfehler behebt?

Ciao
Peter Schütt

[Matthias Eißing]

Post by Peter Schütt
Und? Wann kommt das Update von XE7, dass den Speicherfehler behebt?

Große Projekte erfordern zur Übersetzung nunmal viel Speicher...

Mit den größer werdenden Projekten (ich habe Projekte mit 20+ Millionen
LOC gesehen) ist der Bedarf nach einer passenden IDE immer wichtiger.

Die Umstellung der IDE auf ein anderes Speichermodell rechtfertigt IMHO
schon eine neue Version (=Update)

[Soeren Muehlbauer]

Hi,

Post by Matthias Eißing

Post by Peter Schütt
Und? Wann kommt das Update von XE7, dass den Speicherfehler behebt?

Große Projekte erfordern zur Übersetzung nunmal viel Speicher...
Mit den größer werdenden Projekten (ich habe Projekte mit 20+ Millionen
LOC gesehen) ist der Bedarf nach einer passenden IDE immer wichtiger.
Die Umstellung der IDE auf ein anderes Speichermodell rechtfertigt IMHO
schon eine neue Version (=Update)

Was meinst Du mit anderem Speichermodel? Meinst Du das Exe-Flag
LargeAdressAware? Jo das wäre eine ganz große Leistung (Vorsicht
Ironie). Bei uns macht nicht das Kompilieren Probleme, sondern das
Debuggen (Der Kompiler hängt auch gelegentlich, damit können wir leben).
Hat sich in diesem Umfeld was getan? Ich sag Dir, meine Firma hat für 20
Entwickler immer Lizenzen gekauft. Kannst Dir ja selber ausrechnen von
welchen Summen wir sprechen. Und ich lade Dich ganz herzlich ein, mal
ein bis zwei Tage zu uns zu kommen. Da kannst Du Dir das Elend (XE7)
live anschauen...

Sören

PS: Wir können mit den gelegentlichen Kompilerproblemen leben, weil wir
uns ein eigenes Tool geschrieben haben, welches hochgradig parallel alle
unsere Dll's kompiliert. Das kompiliert parallel auch noch die zu dem
Delphi Teil gehörende ASP.NET Anwendung samt Assemblies (inkl. Auflösen
der Abhängigkeiten). Das Tool ist aber nicht in Delphi geschrieben.
Hätte damit wesentlich länger gedauert und das obwohl das meiste Wissen
bei uns im Delphiumfeld zu finden ist.

[Matthias Eißing]

Post by Soeren Muehlbauer
Was meinst Du mit anderem Speichermodel? Meinst Du das Exe-Flag
LargeAdressAware? Jo das wäre eine ganz große Leistung (Vorsicht
Ironie).

Dann brauchen wir hier ja nicht weiter zu diskutieren.

[Soeren Muehlbauer]

Hi,

Post by Matthias Eißing

Post by Soeren Muehlbauer
Was meinst Du mit anderem Speichermodel? Meinst Du das Exe-Flag
LargeAdressAware? Jo das wäre eine ganz große Leistung (Vorsicht
Ironie).

Dann brauchen wir hier ja nicht weiter zu diskutieren.

Also doch. Das ist genau das, was hier bei uns alle so richtig ärgert.
Da wird ein total banales Feature, wofür EMBT nicht viel tun musste,
aufgebläht. Aber ein stabiles, benutzbares Produkt, was Spaß macht, wird
damit daraus nicht.

Ich sagte es in meinem anderen Post bereits. EMBT/CodeGear/Borland hat
sehr viel verspielt. Meine Chefs kaufen kein Produkt mehr, wenn nicht
ein absolutes Killerfeature dabei ist. Das was derzeit am meisten weh
tut ist der für uns katastrophale Debugger.

Sören

PS: Und ehrlich, sich einer Diskussion auf diese Art zu entziehen ist
nicht gerade kundenbindend. Wir ackern uns auch für 0815 Kunden ab und
geben Support. Was ich bisher an Support von EMBT erhalten habe ist
nicht wirklich erwähnenswert.

[Matthias Eißing]

Post by Soeren Muehlbauer
Hi,

Post by Matthias Eißing

Post by Soeren Muehlbauer
Was meinst Du mit anderem Speichermodel? Meinst Du das Exe-Flag
LargeAdressAware? Jo das wäre eine ganz große Leistung (Vorsicht
Ironie).

Dann brauchen wir hier ja nicht weiter zu diskutieren.

Also doch. Das ist genau das, was hier bei uns alle so richtig ärgert.
Da wird ein total banales Feature, wofür EMBT nicht viel tun musste,
aufgebläht. Aber ein stabiles, benutzbares Produkt, was Spaß macht, wird
damit daraus nicht.

Banales Features?

IBTD. Da steckt einiges mehr dahinter. Siehe MSDN Artikel zu
Large-Address-Awareness.

Post by Soeren Muehlbauer
PS: Und ehrlich, sich einer Diskussion auf diese Art zu entziehen ist
nicht gerade kundenbindend. Wir ackern uns auch für 0815 Kunden ab und
geben Support. Was ich bisher an Support von EMBT erhalten habe ist
nicht wirklich erwähnenswert.

- Ich vertrete hier meine persönliche Meinung
- Ich habe explizit nachgeschaut, welche Support-Cases ihr in den letzten
Jahren geloggt habt. Kein einziges Mal wurde ein Problem mit dem Debugger
in den letzten Jahren gemeldet.

[Soeren Muehlbauer]

Hi,

Post by Matthias Eißing

Post by Soeren Muehlbauer
Also doch. Das ist genau das, was hier bei uns alle so richtig ärgert.
Da wird ein total banales Feature, wofür EMBT nicht viel tun musste,
aufgebläht. Aber ein stabiles, benutzbares Produkt, was Spaß macht, wird
damit daraus nicht.

Banales Features?

Doch es ist total banal. FastMM kann das schon jahrelang. Ist ja sogar
der Default-Memory-Manager seit einigen Delphi Versionen.

Post by Matthias Eißing
IBTD. Da steckt einiges mehr dahinter. Siehe MSDN Artikel zu
Large-Address-Awareness.

Ach. Sag an.

Post by Matthias Eißing

Post by Soeren Muehlbauer
PS: Und ehrlich, sich einer Diskussion auf diese Art zu entziehen ist
nicht gerade kundenbindend. Wir ackern uns auch für 0815 Kunden ab und
geben Support. Was ich bisher an Support von EMBT erhalten habe ist
nicht wirklich erwähnenswert.

- Ich habe explizit nachgeschaut, welche Support-Cases ihr in den letzten
Jahren geloggt habt. Kein einziges Mal wurde ein Problem mit dem Debugger
in den letzten Jahren gemeldet.

Ich kann Dir gerne meine Mail Korrespondenz diesbezüglich mit Marco
Cantu zur Verfügung stellen. Wenn ich mit dem Produktmanager Nachrichten
austausche, so gehe ich doch wohl davon aus, dass das Problem intern
erfasst wird. Wieso bin ich als Kunde noch in der Pflicht einen Eintrag
in das Bugtracking System vorzunehmen.
Für mich bedeutet das entweder, dass es dem Hersteller egal ist, oder
das es intern doch erfasst wurde.

Dieser hier ist seit über einem Jahr offen und verhindert, dass wir das
eigentlich tolle Feature "parallel" nutzen können. Und es zeigt, wie
wenig Kenntnis über Windows bei den Entwicklern da ist, oder das einfach
die Sorgfalt und Qualitätskontrolle mangelhaft ist. Es könnte auch ein
Hinweis darauf sein, dass Features halbgar abgeliefert werden.

http://qc.embarcadero.com/wc/qcmain.aspx?d=128762


Der Bug ist bereits seit 2010 offen und bringt Probleme mit Hints von
Formularen aus DLL's.

http://qc.embarcadero.com/wc/qcmain.aspx?d=85705

Auch sowas, warum wir die RTL/VCL patchen. Da bleiben dann teilweise
Artefakte von Hintfenstern stehen, oder es gibt tolle Exceptions

Auch schon 2 Jahre offen:

http://qc.embarcadero.com/wc/qcmain.aspx?d=114824

Und das sind nur die Probleme, wo ich bereit war einen Eintrag zu
machen, weil ich ja weiß wie die Bugfixing Bereitschaft bei EMBT/Borland
ist oder zumindest war. Vor allem habe ich nichts davon so einen Eintrag
zu machen, weil ich, um an den Fix zu kommen wieder Geld ausgeben muss.
Das ist keine Logik, wonach ich motiviert bin einer Firma zu helfen ihr
Produkt in Ordnung zu bringen.

Sören

[Matthias Eißing]

Am 17.09.15 um 11:27 schrieb Soeren Muehlbauer:

[Large Address Awareness]

Post by Soeren Muehlbauer
Doch es ist total banal. FastMM kann das schon jahrelang. Ist ja sogar
der Default-Memory-Manager seit einigen Delphi Versionen.

Das ist IMHO nicht so ganz vergleichbar.

Post by Soeren Muehlbauer

Post by Matthias Eißing
IBTD. Da steckt einiges mehr dahinter. Siehe MSDN Artikel zu
Large-Address-Awareness.

Ach. Sag an.

Ja.

Post by Soeren Muehlbauer
Ich kann Dir gerne meine Mail Korrespondenz diesbezüglich mit Marco
Cantu zur Verfügung stellen. Wenn ich mit dem Produktmanager Nachrichten
austausche, so gehe ich doch wohl davon aus, dass das Problem intern
erfasst wird. Wieso bin ich als Kunde noch in der Pflicht einen Eintrag
in das Bugtracking System vorzunehmen.

Weil Marco kein Support-Mitarbeiter ist?
Marco dürfte bekannt genug sein, um das zu wissen... und Marco weisst iA
auch darauf hin, das man Support Cases auch immer an den Support melden
soll.

Post by Soeren Muehlbauer
Für mich bedeutet das entweder, dass es dem Hersteller egal ist, oder
das es intern doch erfasst wurde.

In jedem Unternehmen gibt es Prozesse. Auch bei uns.

Damit das jedem klar ist, haben wir das in den Support-Bedingungen genau
aufgeschlüsselt...

Post by Soeren Muehlbauer
http://qc.embarcadero.com/wc/qcmain.aspx?XXXX

Quality Central ist kein Support. Es ist eine Möglichkeit (für jeden)
Bugs/Wünsche/Vorstellungen einzukippen, die unregelmäßig begutachtet werden.

Nochmals: Welche Fälle aus dem Support sind akut?
(Ihr hattet einen Support-Vetrag.... aber nie genutzt)

[Soeren Muehlbauer]

Hi,

Post by Matthias Eißing

Post by Soeren Muehlbauer
Ich kann Dir gerne meine Mail Korrespondenz diesbezüglich mit Marco
Cantu zur Verfügung stellen. Wenn ich mit dem Produktmanager Nachrichten
austausche, so gehe ich doch wohl davon aus, dass das Problem intern
erfasst wird. Wieso bin ich als Kunde noch in der Pflicht einen Eintrag
in das Bugtracking System vorzunehmen.

Weil Marco kein Support-Mitarbeiter ist?
Marco dürfte bekannt genug sein, um das zu wissen... und Marco weisst iA
auch darauf hin, das man Support Cases auch immer an den Support melden
soll.

Wenn es einem Unternehmen wichtig genug ist, so kümmert sich der
Produktmanager darum. Zumal Marco auch andere Leute darauf angesprochen
hat.

Post by Matthias Eißing

Post by Soeren Muehlbauer
Für mich bedeutet das entweder, dass es dem Hersteller egal ist, oder
das es intern doch erfasst wurde.

In jedem Unternehmen gibt es Prozesse. Auch bei uns.

Der Prozess heißt also: Kunde meldet Problem->Wir tun so als ob wir was
tun->Wir erkennen das Problem->Kunde muss sich halt selbst kümmern

Post by Matthias Eißing
Damit das jedem klar ist, haben wir das in den Support-Bedingungen genau
aufgeschlüsselt...

Jo, so kann man sich doch schön hinter irgendwelchen Bedingungen
verstecken. Dumm nur, dass dort nicht drinsteht, dass wir auch nur noch
eine Version von Euch kaufen.

Post by Matthias Eißing

Post by Soeren Muehlbauer
http://qc.embarcadero.com/wc/qcmain.aspx?XXXX

Quality Central ist kein Support. Es ist eine Möglichkeit (für jeden)
Bugs/Wünsche/Vorstellungen einzukippen, die unregelmäßig begutachtet werden.

Dann schaltet das ab. Sowas braucht keiner.

Post by Matthias Eißing
Nochmals: Welche Fälle aus dem Support sind akut?
(Ihr hattet einen Support-Vetrag.... aber nie genutzt)

Meinst Du allen ernstes, dass hätte uns geholfen? Ich glaub das eher nicht.

Sören

[Matthias Eißing]

Post by Soeren Muehlbauer
Meinst Du allen ernstes, dass hätte uns geholfen? Ich glaub das eher nicht.

Ja.

(Ihr habt es ja nochnichtmal ausprobiert....)

[Soeren Muehlbauer]

Hallo,

Post by Matthias Eißing

Post by Soeren Muehlbauer
Meinst Du allen ernstes, dass hätte uns geholfen? Ich glaub das eher nicht.

Ja.
(Ihr habt es ja nochnichtmal ausprobiert....)

Ich habe direkt mit dem Produktmanager in Kontakt gestanden. Direkter
geht ja wohl kaum noch. Gab es bei Euch schon jemals einen Kunden, der
einen Bug behoben bekommen hat? Zumal das Problem mit dem
resourcenverschwendenen Debugger sicher nicht mal nebenbei gefixt werden
kann. So kommen mir doch starke Zweifel an Deiner Argumentation. Wenn
Embarcadero Interesse an uns als Kunden gehabt hätte, so hätte Marco
doch mehr Einsatz gezeigt. Hat er aber nicht.

Siehste, und auf die schon seit Jahren offenen Bugs bist Du nicht
eingegangen. War mir schon klar.

Mal wieder etwas ontopic. Warum gibt es in Delphi nicht so etwas wie in C#:

public interface ITestClass
{
string Name { get; set; }
}

public class TestClass: ITestClass
{
public string Name { get; set; }
}

Wenn ich das mit Delphi schreibe kommt sowas bei raus:

type
ITestClass = interface
[IID]
function Get_Name: WideString; safecall;
procedure Set_Name(const Value: WideString); safecall;
property Name: WideString read Get_Name write Set_Name;
end;

TTestClass = class(TInterfacedObject, ITestClass)
protected
function Get_Name: WideString; safecall;
procedure Set_Name(const Value: WideString); safecall;
public
property Name: WideString read Get_Name write Set_Name;
end;

Ich muss soviel Quelltext manuell pflegen. Ich hab bisher auch keine
zuverlässige Möglichkeit eine Schnittstelle zu implementieren.

Warum geht sowas nicht:

type
ITestClass = interface
[IID]
property Name: WideString read write;
end;

TTestClass = class(TInterfacedObject, ITestClass)
public
property Name: WideString read write;
end;


Das wäre alles nur syntaktischer Zucker, der aber das RAD in RAD Studio
wieder in den Fokus rücken würde.

Ebenso die Lamda (oder anonyme Methoden). In Oxygene gehts auch. ()->
oder ()=> in C#.


Auf jeden Fall neigt sich, bei mir privat, wie auch perspektivisch auf
Arbeit der Einsatz von Delphi dem Ende, auch weil scheinbar bei EMBT
keiner bereit ist zuzuhören und man sich als Kunde (man fragt sich
manchmal, ob man auch so gesehen wird) dann noch irgendwas vorwerfen
lassen muss...

Sören

[Hans-Peter Diettrich]

Post by Matthias Eißing
Quality Central ist kein Support. Es ist eine Möglichkeit (für jeden)
Bugs/Wünsche/Vorstellungen einzukippen, die unregelmäßig begutachtet werden.
Nochmals: Welche Fälle aus dem Support sind akut?
(Ihr hattet einen Support-Vetrag.... aber nie genutzt)

Hmmm, es reicht also nicht, daß die Benutzer für das Produkt bezahlen,
sondern nochmal für die Umgehung oder Behebung der Fehler zahlen müssen,
die sich darin befinden?

Wenn die Firmenleitung so rechnet, dann wird mir klar, warum die
Beseitigung von Fehlern (=Einnahmequelle) so weit unten auf der Agenda
steht. Insbesondere die Beseitigung bekannter Fehler, deren Umgehung vom
Support per Textbaustein bearbeitet werden kann :-]

Vielleicht sollte man mal überdenken, daß Programmentwickler
möglicherweise auch als *Kunden* andere Vorstellungen oder Ansprüche an
die Qualität von Programme haben, als Leute die Rechner aus Langeweile
benutzen und über jedes neue Fietscher begeistert sind. Ganz zu
schweigen von deren Vorgesetzten, die ihre eigenen Konsequenzen ziehen,
wenn ihre RAD Studio Abteilung teurer oder ineffizienter arbeitet als
die Benutzer anderer Tools. Wenn dann bei neuen Projekten die
Kompatibilität mit einer alten Codebasis kein Argument mehr ist, fällt
die Entscheidung zwischen mehreren Tools ziemlich leicht.


Ich erinnere mich wehmütig noch an die Zeiten, als es in den Delphi
Foren mehr um die Probleme mit eigenen Projekten ging, als um Probleme
mit den Entwicklungswerkzeugen. Damals wurden Leute wie Matthias und
TeamB mit Lob für ihre Unterstützung überschüttet, während sie heute
hauptsächlich den Frust der Anwender ertragen müssen.

Früher wurden Software-Entwickler mit Dealern verglichen, die ihre
Kunden nur anfixen müssen, um sie nachher ausnehmen zu können. Heute
drängt sich mir noch ein Vergleich mit Schleusern auf, die ihre Kunden
in ein RAD (Rettungsboot a.D.) stecken, und sie dann auf hoher See ihrem
Schicksal überlassen. Oder ist da eine Version in Sicht, in der alle
bekannten Fehler beseitigt sind, und die Online-Hilfe wieder wirklich
hilfreich ist? Vorläufig fehlt mir immer noch eine XE Version, mit der
die Entwicklung von Programmen so fix geht und so viel Freude bereitet
wie mit D7.

SCNR
DoDi

[Matthias Eißing]

Post by Hans-Peter Diettrich
Hmmm, es reicht also nicht, daß die Benutzer für das Produkt bezahlen,
sondern nochmal für die Umgehung oder Behebung der Fehler zahlen müssen,
die sich darin befinden?

Gibt es einen Softwarehersteller, der das anders handhabt?

Immherhin ist bei Embarcadero der Support optional...

Post by Hans-Peter Diettrich
Wenn die Firmenleitung so rechnet, dann wird mir klar, warum die
Beseitigung von Fehlern (=Einnahmequelle) so weit unten auf der Agenda
steht. Insbesondere die Beseitigung bekannter Fehler, deren Umgehung vom
Support per Textbaustein bearbeitet werden kann :-]

Auch bei dir sehe ich keinen Support-Fall in den letzten Jahren....
keinen einzigen.

Woher die Aussage mit dem "Textbaustein"?


[Rest gesnippt, da irrelevant]

[Hans-Peter Diettrich]

Post by Matthias Eißing
Auch bei dir sehe ich keinen Support-Fall in den letzten Jahren....
keinen einzigen.

Ganz einfach, weil mich die vielen Fehler beim Ausprobieren davon
abgehalten haben, damit ernsthaft weiterzuarbeiten, und dem schlecht
investierten Geld auch noch gutes für Support hinterherzuwerfen.

DoDi

[Matthias Eißing]

Post by Hans-Peter Diettrich

Post by Matthias Eißing
Auch bei dir sehe ich keinen Support-Fall in den letzten Jahren....
keinen einzigen.

Ganz einfach, weil mich die vielen Fehler beim Ausprobieren davon
abgehalten haben, damit ernsthaft weiterzuarbeiten, und dem schlecht
investierten Geld auch noch gutes für Support hinterherzuwerfen.

Woher dann die "Erfahrung" mit den Textbausteinen?

[Hans-Peter Diettrich]

Post by Matthias Eißing

Post by Hans-Peter Diettrich

Post by Matthias Eißing
Auch bei dir sehe ich keinen Support-Fall in den letzten Jahren....
keinen einzigen.

Ganz einfach, weil mich die vielen Fehler beim Ausprobieren davon
abgehalten haben, damit ernsthaft weiterzuarbeiten, und dem schlecht
investierten Geld auch noch gutes für Support hinterherzuwerfen.

Woher dann die "Erfahrung" mit den Textbausteinen?

Das bezieht sich auf die übliche Antwort auf Fehlermeldungen (QC...) "in
der nächsten Version...".

DoDi

[Peter Schütt]

Hallo,

Post by Matthias Eißing

Post by Peter Schütt
Und? Wann kommt das Update von XE7, dass den Speicherfehler behebt?

Große Projekte erfordern zur Übersetzung nunmal viel Speicher...

Die IDE bekommt ihre OutOfMemory-Meldung, da liegt ihr Verbrauch im
Taskmanager ungefähr bei 1.2 GB. Ich habe aber 8 GB. Warum wird nicht
zumindest mehr von den 3.5 GB für 32-Bit-Programme genutzt?

Post by Matthias Eißing
Mit den größer werdenden Projekten (ich habe Projekte mit 20+ Millionen
LOC gesehen) ist der Bedarf nach einer passenden IDE immer wichtiger.

Mit Netbeans unter Java (ich nutze es seit 5 Jahren) hatte ich mit solch
großen Projekten noch nie Problem. U.U. musste ich den
Konfigurationsparameter für den Speicherverbrauch hochdrehen (den es unter
Java gibt!).

Aber vielleicht ist der Vergleich ja auch unfair, da Java ja schon immer als
besonders speichereffizient bekannt war.

Post by Matthias Eißing
Die Umstellung der IDE auf ein anderes Speichermodell rechtfertigt IMHO
schon eine neue Version (=Update)

Aber die Version XE7 ist buggy. Aber vielleicht gibt es auch irgendwo eine
Spezifikation, wie groß Delphi-Projekte sein dürfen, bevor die IDE nicht
mehr richtig mitspielt.

Dann hätte man sich vorher überlegen, ob man upgraded. Unter XE war es noch
nicht ganz so schlimm und ohne die zusammengegooglten Tools wie IDE-Fix wäre
XE7 völlig unbenutzbar.

Aber Sie als Vertreter von Embarcadero treten hier so auf, als wäre das
richtig so, als sei man selbst schuld, dass man so blöde war, so eine Buggy-
Version zu kaufen.

Ich vermisse jegliches Problembewußtsein bei Ihnen. Zumindest kommen Sie
hier so rüber.

Ist Ihnen nicht bewusst, wie schwierig es ist, für wirklich viel Geld eine
IDE für 10 Personen dem Abteilungsleiter aufzuschwatzen, wenn die reinen
Java-Abteilungen ihre IDE entweder umsonst oder für 199€ (IntelliJ)
bekommen? Und die sind nicht so buggy. Das Refactoring funktioniert seit
mindestens 10 Jahren schon fehlerfrei (in XE7 gibt es immer noch Fehler).

Ich verstehe Ihre (als ihre Firma) gesamte Firmenpolitik, Ihr gesamtes
Auftreten nicht.

Ciao
Peter Schütt

[Matthias Eißing]

Post by Peter Schütt
Ich vermisse jegliches Problembewußtsein bei Ihnen. Zumindest kommen Sie
hier so rüber.

....und ich verstehe die Leute nicht, die ein Problem haben (nein, daß
es Probleme gibt, steht außer Frage) und sich nicht um Hilfe bemühen.

Auch von Dir sehe ich keine einzige, konkrete Support-Anfrage....

(Ja... wir haben Kunden mit Delphi XE5..6..7... die Probleme
haben/hatten... und dieser Probleme mit dem Support zusammen gelöst. Die
Erfahrungen sind jetzt in das "Delphi 10 Seattle" eingeflossen. Für XE7
und XE8 wird es dafür auch Fixes geben.... für Support-Kunden)

[Peter Schütt]

Hallo,

Post by Matthias Eißing

Post by Peter Schütt
Ich vermisse jegliches Problembewußtsein bei Ihnen. Zumindest kommen Sie
hier so rüber.

....und ich verstehe die Leute nicht, die ein Problem haben (nein, daß
es Probleme gibt, steht außer Frage) und sich nicht um Hilfe bemühen.

Ohne Support-Vertrag gibt es keine Hilfe. Das scheint doch ein klares
Statement zu sein.

Post by Matthias Eißing
Auch von Dir sehe ich keine einzige, konkrete Support-Anfrage....

Geht das ohne Support-Vertrag? Oder seit ihr der Meinung, dass man ohne
Support-Vertrag keinen Anspruch auf ein funktionierendes Produkt hat?

Ich stelle mir Support eher so vor:

Es gibt einen kostenlosen Basis-Support für alle Kunden, der dazu beiträgt,
dass man das Produkt vernünftig benutzen kann.
Das wäre für XE7 _mindestens_ die Mitausliefungerungen der IDE-Fixes oder
zumindest ein Hinweis darauf gewesen. Denn ohne hatten wir schon
OutOfMemory-Exceptions, wenn wir nur ein kompliziertes Formular geöffnet
haben. So haben wir nur noch durchschnittlich drei Abstürze pro Tag und auch
nur wenn wir unsere Projektgruppe außerhalb der IDE mittels Batch
compilieren. Innerhalb der IDE geht das sowieso nicht mehr (schon unter XE
nicht mehr).

Dann gibt es den kostenpflichtigen Premium-Support, wo man Beratung für
fortgeschrittene Programmierprobleme und dergleichen bekommt.

So kenne ich das von anderen Produkten.

Die Frage ist natürlich, ob jemand überhaupt einen Premium-Support buchen
würde, wenn das Produkt an sich schon so buggy ist. Denn wenn es Experten
gibt, warum haben die das nicht besser hinbekommen?

Post by Matthias Eißing
(Ja... wir haben Kunden mit Delphi XE5..6..7... die Probleme
haben/hatten... und dieser Probleme mit dem Support zusammen gelöst. Die
Erfahrungen sind jetzt in das "Delphi 10 Seattle" eingeflossen. Für XE7
und XE8 wird es dafür auch Fixes geben.... für Support-Kunden)

Es wird Fixes geben, die das Speicherproblem in XE7 lösen?

Und diese Fixes sind also kostenpflichtig.

Nun werde doch bitte 'mal konkret. Wie teuer sollen die sein?
Für uns wäre das sehr interessant.

Ciao
Peter Schütt

[Matthias Eißing]

Post by Peter Schütt
Nun werde doch bitte 'mal konkret. Wie teuer sollen die sein?
Für uns wäre das sehr interessant.

http://support.embarcadero.com/annual

[Peter Schütt]

Hallo,

Post by Matthias Eißing

Post by Peter Schütt
Nun werde doch bitte 'mal konkret. Wie teuer sollen die sein?
Für uns wäre das sehr interessant.

http://support.embarcadero.com/annual

Ich kann den Preis nicht finden. Kannst Du da was zu sagen?

Ich habe gesehen, ihr bietet auch "Single Incident Support".

Könnte man nicht die Lösung des Speicherproblems darüber erwerben?
Das wäre meiner Ansicht nach ein konstruktiver Weg.

Aber bevor ich mit irgendeinem Vorgesetzen spreche, muss ich irgendwelche
Zahlen haben.

Und ein Upgrade auf Delphi XE10 wird im Augenblick sowieso nicht gehen. Die
Fremdkomponenten gibt es zum Teil noch nicht und der Test, ob das überhaupt
gehen würde, kostet ja Zeit und Aufwand, die die Firma auch aufwenden muss.

Und definitiv: Wir können nicht prinzipiell alle 2 Jahre eine neue Delphi-
Version kaufen. Dafür ist der Nutzen der neuen Version im Verhältnis zum
Preis oft zu gering. Und wenn wir vorher gewusst hätten, was uns mit XE7
erwartet, wären wir wohl bei XE oder XE2 geblieben.
Ich nehme an, mit XE8 ist die Speichersituation noch schlechter geworden.

Ihr habt ein gewissen Glaubwürdigkeitsproblem, deswegen fällt es mir auch
schwer in das "Juhuu Delphi XE 10" einzustimmen.

Schließlich hat Euer Marketing zu XE 7 ähnliches gesagt (ein Werbe-Video bei
YouTube):

"Delphi XE7 is a must-have upgrade for all Delphi developers" (aber nicht
für die mit den großen Projekten).

So, jetzt ist aber genug gemotzt.

Die Anfrage, das Speicherproblem über einen "Single Incident Support" zu
lösen, ist ernstgemeint.

Ciao
Peter Schütt

[Matthias Eißing]

Post by Peter Schütt
Ich kann den Preis nicht finden. Kannst Du da was zu sagen?

Support (neudeutsch: Update-Subscription) Preise findet man hier:
(Das passende Produkt in den Warenkorb legen):
http://store.embarcadero.com/542/catalog/category.1582/language.de/currency.EUR/buy-delphi-online

zB Delphi Professional: 373,- EUR (pro Jahr und User)

Post by Peter Schütt
Ich habe gesehen, ihr bietet auch "Single Incident Support".
Könnte man nicht die Lösung des Speicherproblems darüber erwerben?

Faktisch nicht (da individuelle Patches im Incident Support
ausgeschlossen sind)

Post by Peter Schütt
Ihr habt ein gewissen Glaubwürdigkeitsproblem, deswegen fällt es mir auch
schwer in das "Juhuu Delphi XE 10" einzustimmen.

Die einen sagen "so", die anderen sagen "so"...seit 20 Jahren. Ich habe
mich daran gewöhnt ;-)

[Peter Schütt]

Hallo,

Post by Matthias Eißing

Post by Peter Schütt
Ich kann den Preis nicht finden. Kannst Du da was zu sagen?

http://store.embarcadero.com/542/catalog/category.1582/language.de/currency.EUR/buy-delphi-online

Post by Matthias Eißing
zB Delphi Professional: 373,- EUR (pro Jahr und User)

Wie sicher kann ich mir denn sein, dass wir im Rahmen eines Jahres-Support-
Vertrags das IDE-OutOfMemory-Problem gelöst bekommen?

Post by Matthias Eißing

Post by Peter Schütt
Ich habe gesehen, ihr bietet auch "Single Incident Support".
Könnte man nicht die Lösung des Speicherproblems darüber erwerben?

Faktisch nicht (da individuelle Patches im Incident Support
ausgeschlossen sind)

Was heißt "individuell"? Wenn Ihr das Problem gelöst habt, dann könnt ihr
das doch an alle Interessierten ausrollen. Oder gibt es für jeden einzelnen
Support-Vertrag einen eigenen Branch der IDE.

Post by Matthias Eißing

Post by Peter Schütt
Ihr habt ein gewissen Glaubwürdigkeitsproblem, deswegen fällt es mir auch
schwer in das "Juhuu Delphi XE 10" einzustimmen.

Die einen sagen "so", die anderen sagen "so"...seit 20 Jahren. Ich habe
mich daran gewöhnt ;-)

Ich nutze mit Unterbrechungen sind Ende '95 Delphi und die allgemeine
Begeisterung hat sicherlich nachgelassen.

Wer würde denn mit Delphi jetzt noch ein Großprojekt beginnen? Ihr lebt doch
von denen, die nicht aus Delphi 'raus können.

Dazu verschreckt ihr den Nachwuchs, indem ihr die kostenlosen Schullizenzen
abgeschafft habt. An der Schule meines Sohns wurde früher im
Informatikunterricht Delphi verwendet. Dann wollte Embarcadero Geld von der
Schule und jetzt wird in Java unterrichtet.

Die Schulen haben keine jahrealten Delphi-Projekte, die sie dazu zwingen
Delphi zu verwenden. Schulen haben wenig Geld, also werden kostenlose Tools
verwendet.

Embarcadero verdient jetzt keinen Cent mehr, aber es hat die Axt an die
eigene Zukunft gelegt.

Früher war Delphi ein Inbegriff der Qualität: Schneller Compiler, schnelle
stabile IDE, guter GUI-Builder. Und jetzt? Jetzt ist das Netz voll von
Gejammer über die Delphi-IDE. Wie konnte es soweit kommen?
Warum wurde das Speicherproblem über all die Jahre nicht gelöst?

Ciao
Peter Schütt

[Matthias Eißing]

Post by Peter Schütt
Wie sicher kann ich mir denn sein, dass wir im Rahmen eines Jahres-Support-
Vertrags das IDE-OutOfMemory-Problem gelöst bekommen?

Mit Delphi 10 Seattle treten diese nicht mehr auf (so die Rückmeldung
etlicher Kunden)

Post by Peter Schütt
Früher war Delphi ein Inbegriff der Qualität: Schneller Compiler, schnelle
stabile IDE, guter GUI-Builder. Und jetzt? Jetzt ist das Netz voll von
Gejammer über die Delphi-IDE. Wie konnte es soweit kommen?
Warum wurde das Speicherproblem über all die Jahre nicht gelöst?

Es ist (weitestgehend, nach bestem Wissen und Gewissen) gelöst.

Kleiner Blick in das Subject?
Auch hier habe ich noch nichts Nachteiliges zu Delphi 10 Seattle gehört...

[Hans-Peter Diettrich]

Post by Peter Schütt
Früher war Delphi ein Inbegriff der Qualität: Schneller Compiler, schnelle
stabile IDE, guter GUI-Builder. Und jetzt? Jetzt ist das Netz voll von
Gejammer über die Delphi-IDE. Wie konnte es soweit kommen?
Warum wurde das Speicherproblem über all die Jahre nicht gelöst?

IMO gab es seit D7 Probleme und unterschiedliche Meinungen, was noch zu
verbessern wäre. Kylix war ein Flop, weil die Anpassung an ständig neue
Kernel und Oberflächen sehr aufwendig ist. Deshalb wurde wohl auch auf
Crosscompiler umgestellt, statt auf eine multiplattform IDE. CLX wurde
nicht weiter verfolgt, hätte IMO ein Erfolg werden können, doch das
hätte den Aufkauf oder permanente Abhängigkeit von Qt bedeutet. Diese
Schiene wurde später mit FireMonkey fortgeführt.

Ein 64 Bit Compiler wurde verschlafen, stattdessen ging man auf
Konkurrenzkurs zu Microsoft (.NET...), und zwar nicht mit einem .NET
Plugin für Pascal, sondern gleich mit einer kompletten IDE. Hier
scheiterte die Integration (VCL.NET) wegen zu vieler Inkompatibilitäten,
RemObjects hat das unter Verzicht auf die VCL besser hingekriegt. Und
bei der Umstellung von WinHelp auf HTML-Hilfe, als Voraussetzung für
Zugriff auf die aktuelle Windows Hilfe, blieb die zuvor hervorragende
Dokumentation der RTL und VCL auf der Strecke.

Und dann wurden noch die Spitzenentwickler von Microsoft abgeworben.
Seitdem weiß anscheinend niemand mehr, wie das Wirthsche Modell von
Programmiersprachen *richtig* umzusetzen und zu erweitern ist.

Die Umstellung auf Unicode ging relativ schmerzfrei über die Bühne, nur
die eigentlich clevere Verwendung von AnsiStrings (mit Encoding) wurde
durch Laufzeitoptimierung bis zur Unbrauchbarkeit verkrüppelt
(unterschlagene RawByteString Konvertierung bei Zuweisungen).

Ebenfalls verschlafen wurde die Umstellung der IDE auf 64 Bit, während
die Datenmenge mit ExtendedRTTI etc. immer weiter anwuchs - kein Wunder,
daß es jetzt am Speicher klemmt. Hier muß sich der Hersteller eigentlich
fragen (lassen), warum es inzwischen so einfach sein soll, 64 Bit
Programme zu entwickeln, während sich die IDE nicht ebenso einfach auf
64 Bit umstellen läßt. Das klingt nach heftigen Problemen, die vor den
Benutzern versteckt werden. Ob das ein weiterer Grund für den
kostenpflichtigen Support ist, bei dem Probleme hinter verschlossenen
Türen besprochen und gelöst werden?

Und durch das Propagieren immer neuer Features, zu Lasten einer
konsistenten Weiterentwicklung und Behebung bekannter Probleme, ging die
Qualität den Bach runter, und damit die Verkaufszahlen. Die Entwickler,
die mit ihren bestehenden Projekten nicht einfach auf andere
Entwicklungssysteme umsteigen können (Lazarus ist keine Alternative
mehr, RemObjects völlig inkompatibel), werden zusätzlich für Support zur
Kasse gebeten, doch ist abzusehen, daß dieser Ast auch bald wegbricht.

Da kann ich nur nochmal die Embarcadero-Mitarbeiter bedauern, die diese
Misere den Kunden erklären oder gar schmackhaft machen sollen :-(

DoDi

[Soeren Muehlbauer]

Hi,

Post by Matthias Eißing

Post by Peter Schütt
Ich vermisse jegliches Problembewußtsein bei Ihnen. Zumindest kommen Sie
hier so rüber.

Das sehe ich auch so.

Post by Matthias Eißing
....und ich verstehe die Leute nicht, die ein Problem haben (nein, daß
es Probleme gibt, steht außer Frage) und sich nicht um Hilfe bemühen.
Auch von Dir sehe ich keine einzige, konkrete Support-Anfrage....

Nochmal: ICH habe mit dem PRODUKTMANAGER von Delphi in Kontakt
gestanden. Zu einer Zeit, wo wir Deiner Angabe nach noch einen
Supportvertrag hatten. Wieso wurde uns nicht geholfen? Ganz einfach: Das
ist und war die Art und Weise wie EMBT arbeitet.

Post by Matthias Eißing
(Ja... wir haben Kunden mit Delphi XE5..6..7... die Probleme
haben/hatten... und dieser Probleme mit dem Support zusammen gelöst. Die
Erfahrungen sind jetzt in das "Delphi 10 Seattle" eingeflossen. Für XE7
und XE8 wird es dafür auch Fixes geben.... für Support-Kunden)

Na dann her damit. Oder gilt der Support nur, wenn ich auch weiter
fleißig jedes Jahr Geld abdrücke? Lässt sich also Embarcadero seine
schludrige Arbeitsweise am Ende noch bezahlen?

Sören

[Matthias Eißing]

Post by Soeren Muehlbauer
Nochmal: ICH habe mit dem PRODUKTMANAGER von Delphi in Kontakt
gestanden. Zu einer Zeit, wo wir Deiner Angabe nach noch einen
Supportvertrag hatten.

Na... dann schick mir doch mal den Mailverkehr mit ihm...

Post by Soeren Muehlbauer
Na dann her damit. Oder gilt der Support nur, wenn ich auch weiter
fleißig jedes Jahr Geld abdrücke? Lässt sich also Embarcadero seine
schludrige Arbeitsweise am Ende noch bezahlen?

Ist dir ein Subskriptions-Modell lieber?

[Soeren Muehlbauer]

Post by Matthias Eißing

Post by Soeren Muehlbauer
Nochmal: ICH habe mit dem PRODUKTMANAGER von Delphi in Kontakt
gestanden. Zu einer Zeit, wo wir Deiner Angabe nach noch einen
Supportvertrag hatten.

Na... dann schick mir doch mal den Mailverkehr mit ihm...

An welche EMail-Adresse?

Post by Matthias Eißing

Post by Soeren Muehlbauer
Na dann her damit. Oder gilt der Support nur, wenn ich auch weiter
fleißig jedes Jahr Geld abdrücke? Lässt sich also Embarcadero seine
schludrige Arbeitsweise am Ende noch bezahlen?

Ist dir ein Subskriptions-Modell lieber?

Mir ist ein funktionierendes Produkt lieber. Aber da wir auf Delphi
angewiesen sind, fügen wir uns in unser Schicksal...

Sören

[Matthias Eißing]

Post by Soeren Muehlbauer
An welche EMail-Adresse?

Diese hier funktioniert....

wahlweise auch ***@em......com

[Soeren Muehlbauer]

Hi,

Post by Peter Schütt
Man kann mich naiv nennen: Ich würde erwarten, dass die IDE feststellt, wieviel Speicher vorhanden ist und den ausnutzt. Und ich würde auch erwarten, dass es schon seit Jahren eine 64-Bit-IDE gibt.
Und außerdem würde ich erwarten, dass es auch für XE7 einen Service-Pack gibt, der den Speicherfehler behebt. Wir mussten unserem Chef eine Menge Kohle für das Update von XE2 auf XE7 aus dem Etat leiern, in erster Linie dafür, dass die IDE noch öfter abstürzt als vorher.
Anfragen bei Embarcadero in Bezug auf diese Speicherfehler werden mit der kurzen knackigen Botschaft beantwortet: "Neue Version kaufen!"

Wir haben unsere Entwicklung mit D7 begonnen. Danach kamen D2005, D2007,
D2010, XE3 und nun XE7. Jedes mal haben wir ein Haufen Geld in die Hand
genommen, in der Hoffnung nun endlich ein stabiles Produkt zu kaufen.
Und nein, wir können nicht die Trial ausprobieren, da wir einige Fehler
und Probleme in der RTL/VCL selbst patchen und wir daher nicht gegen die
originalen DCU bauen können. Die Probleme, die wir patchen existieren
bereits seit Eonen. Meine Chefs sind eigentlich glühende Delphi
Anhänger. Aber so langsam dämmerts auch bei denen, dass es so nicht
weitergeht.

Wir haben massive Probleme unser Produkt zu debuggen. Wir haben so ca.
50 DLL's. Da hast Du mit XE7 keine Chance. Die RSMs werden auch mit
jeder Version größer und scheinbar meint die IDE auch wirklich jeden
Mist im Speicher halten zu wollen und zu müssen. Ich hab letztens eine
C# Anwendung debuggt, die hatte nahezu 600 Assemblies geladen. Die
Hälfte davon hatte pdb an Board. Die IDE verbrauchte dabei 500MB
Speicher. Debugge ich unsere Delphi Anwendung kann ich froh sein, wenn
ich einen Debuglauf hinbekomme. Wir lösen das derzeit so, dass wir
jedesmal RSM löschen (meist natürlich grad von dem Modul, wo der Fehler
liegt). Die IDE kratzt dabei immer an der 1.6GB Marke. So oft wie ich
die IDE auch zwischendurch neu starten muss, da kommen einem tatsächlich
destruktive Gedanken.

Mein Fazit nach ca. 20 Jahren Delphi: Der Hersteller hat jeglichen
Bonus, den er mal hatte verspielt. Jede Version kann irgendwas neues,
aber nichts kann sie richtig. Überall hakt es und man muss sich
irgendwelche Workarounds einfallen lassen.

Ja und die Antwort vom support kenne ich auch. Ich hatte mal einen email
Verkehr mit Marco Cantu. Aber auch dort ist nichts rausgekommen. Deren
Vorschlag war wieder so ein Workaround (Stelle die Symbole um).

Und man merkt es ja auch in den Newsgroups. Tote Hose (ja ich weiß das
das Medium tot ist). Man kann auch mal bei GitHub vorbeischauen. Da ist
sogar Huskell vor Delphi...

Sören