XE7 Memory verbrauch untragbar.

[Insider2004]

Der Speicher ist fragmentiert durch milliardenfach falsche Allokierung. Das hält nicht mal FastMM aus.

[jaenicke]

Weil es nicht darauf ankommt, ob genügend Gesamtspeicher verfügbar ist, sondern ob ein zusammenhängender Speicherbereich in der gewünschten Größe verfügbar ist.

Dazu kommt, dass der Fehler auch auf Speicherprobleme zurückzuführen sein kann, bei denen z.B. Speicher durch Fehler überschrieben wird. Das kann man von außen erst einmal nicht sehen ohne das genauer zu untersuchen.

[TRomano]

Selbst wenn Emba die IDE auf x64 umstellen könnte bleibt ja das Problem an sich. Nur hätte man dann kurzzeitig den "Erfolg", dass die IDE nicht bei 2GB Verbrauch abstürzen würde. Nur denke ich, dass man dann auch den bequemen Weg gehen würde: "Läuft doch ..." und keine Resourcen in die Qualitätsverbesserung (fehlerhafte Allokierung von Speicher) stecken würde. Leider.

[Bernhard Geyer]

Zitat:

Zitat von Alex_ITA01 (Beitrag 1277076)

Moin zusammen,
mich würde trotzdem mal interessieren, warum hört die IDE bei 1,2GB auf obwohl eine 32bit Anwendung bis zu 2GB kann?

Viele Grüße

Die 2 GB (bzw. 3 GB wenn die Exe mit dem 3GB-Schalter kompiliert wurde) wird eine Anwendung nie erreichen.
Die Exe wird immer dann nicht mehr Speicher bekommen wenn Sie einen Speicherblock der Größe x anfordert, aber im 32-Bit Adressraum nur noch ein durchgehender Bereich der maximalen Größe x-1 Byte verfügbar ist.

[Der schöne Günther]

(Hat sich erledigt!)

Zitat:

Zitat von Der schöne Günther (Beitrag 1276993)

Mit Speicherverbrauch hatte bislang noch keine Probleme, wahrscheinlich sind unsere Projekte alle zu popelig :oops:

´

Jetzt hat es mich auch erwischt- Es ist sogar ein extrem kleines Projekt, allerdings lässt es sich partout nicht auf Win64 kompilieren. Er bricht immer in der selben Zeile ab (markiert sie sogar) und meldet "Nicht genügend Arbeitsspeicher".

Verfolge ich während der Kompilierung die Auslastung im Taskmanager geht der Speicherverbrauch nie über 250 MB! Er ändert sich eigentlich überhaupt nicht.

Ich habe diese "MsBuild"-Geschichte noch überhaupt nicht verstanden. Kann mir das jetzt überhaupt weiterhelfen? Oder muss ich erst einmal alle DCC64-Kommandozeilenschalter auswendig lernen?


Kommando zurück, Andys DCC64 Speedpack deaktiviert und es funktioniert einwandfrei :-(

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1278214)

Ich habe diese "MsBuild"-Geschichte noch überhaupt nicht verstanden.

Gehst du auf "Projektoptionen". Dort unter Delphi-Compiler für die entsprechende Build-Konfiguration die Option "MSBuild extern für die Compilierung verwenden".

[Der schöne Günther]

Ja, den Punkt habe ich über F6 auch gefunden, aber Auswirkungen hatte das auch nicht. Ich wüsste auch nicht, was ich eigentlich hätte erwarten sollen :stupid:

Die "Schuld" lag (zumindest bei mir) am Fixpack

[jbg]

Zitat:

Zitat von Der schöne Günther (Beitrag 1278219)

Die "Schuld" lag (zumindest bei mir) am Fixpack

In welcher Hinsicht? Braucht das Projekt wegen IDE Fix Pack mehr Speicher?

[Der schöne Günther]

Hallo-

Ich habe nur ganz stümperhaft in den Task Manager geschaut, dort überhaupt keine Änderungen am Speicherbedarf sehen können und ungläubig auf den abgebrochenen Kompilierungsvorgang geblickt.

Dann habe ich CompilerSpeedpack64.dll (Version 5.71) aus der Liste der Experten (Registry) entfernt, und nach einem Neustart kompiliert das Projekt anstandslos.

Ich kann über die nächsten Tage da noch einmal genauer nachbohren. Kann ich irgendwie etwas protokollieren lassen das dir weiterhelfen würde?

[kretabiker]

Jetzt kann ich mich auch in den Kreis der Weinenden und Heulenen einreihen...

Dieses Wochenende umgestellt von XE 3 auf XE 7 Upd 1, und prompt bei einer Projektgruppe mit sieben Teilprojekten schon bei den leichtesten Aufgaben auf den Out of Memory-Fehler gestoßen. Die Projektgruppe ist zwar sehr komplex und verwendet auch ebenso komplexe Fremdkomponenten (u.a. RemObjects DataAbstact), aber das war in XE3 kein Problem. Ich habe dann erst einmal alles unter CodeInsight ausgeschaltet, damit ging es etwas besser. Das IdeFixPack für XE 7 hatte ich sicherheitshalber schon vorher deinstalliert.

Ein großes, aber einfaches Projekt (nur ein Projekt in der "Projektgruppe") dagegen machte keine Probleme, egal was ich gemacht habe.

Da scheint XE 7 noch nen heftigen Bug bei komplexeren Projektgruppen zu haben. Eieiei, das wird was werden - gleich mal gucken nach einem QC-Eintrag...

[Bernhard Geyer]

Der Jira-Eintrag ist RSP-9756

[sahimba]

Zitat:

Zitat von kretabiker (Beitrag 1281678)

gleich mal gucken nach einem QC-Eintrag...

Vorhanden. Mehrere. In zumindest einem (der sich auf XE7 bezieht) laufen einige Kunden langsam Sturm. Das Problem ist ja schon länger bekannt, teilweise bereits seit Delphi 2010. Mit XE6 ist das erzeugen einer größeren Projektgruppe kaum mehr möglich. Ich stieß dort auf einen Hinweis, Delphi mit dem Parameter "-noparser" zu starten. Das scheint das Problem zu entschärfen. aber auf die Schnelle hatte ich keine Dokumentation zu dem Schalter gefunden.

[Insider2004]

...seit D2010...Kunden laufen Sturm...! Emba scheint das ja gewaltig zu interessieren! Ich wette, das ist in 5 Jahren noch drin.

[Bernhard Geyer]

nee. wenn schon seit D6 gibts das Problem. In XE7 wurde eine neue Speicherlücke eingebaut

[himitsu]

Zitat:

Zitat von Insider2004 (Beitrag 1281684)

ist in 5 Jahren noch drin.

Neeeee, bis dahin baucht es noch mehr RAM, aber man hat die IDE auf 64 Bit umgestellt.
(ist nur nicht so leicht, da ja auch alle Addons/Plugins/DesignTimePackages in 64 Bit benötigt werden)


Und nein, denn ich persönlich kenn das Problem in XE3 (und das mit nur einem Projekt) und in XE(1) mit einer Projektgruppe.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1281686)

Neeeee, bis dahin baucht es noch mehr RAM, aber man hat die IDE auf 64 Bit umgestellt.

Mir wurde schon von ein Mrd-$ Firma das genau als Lösung vorgeschlagen. Nimm doch die 64-Bit Version

[kretabiker]

In diesem neuen "QC"-Nachfolger namens "Quality" *inhysterischeskichernausbrech* sind ja schon einige Meldungen zu dem Thema. Für den oben genannten habe ich gevotet, was wahrscheinlich gar nichts bewirkt. Wem kann ich noch deswegen auf die Füße treten?

<rant>
Jedenfalls, so ist die IDE unbrauchbar für den praktischen Einsatz. Ich muss bzw. wir müssen mit dem Geraffel Geld verdienen, meinen Kunden ist es pupsegal, ob es mit der IDE Probleme gibt oder nicht - die wissen wahrscheinlich nicht mal, was das ist -, die erwarten zu recht Lieferung.

Für XE7-Installation, Einrichtung der Drittkomponenten und Anpassung der eigenen Projekte (denn natürlich hat es in XE 7 im Vergleich zu XE 3 auch wieder Änderungen gegeben, z.B. bei Indy, aber das ist grundsätzlich in Ordnung) plus Ursachensuche für die Memoryprobleme (es war ja nicht auszuschließen, dass der Fehler doch bei mir liegt), habe ich zehn Stunden gebraucht, nur um dann festzustellen, dass ich mit XE7 letztendlich nicht vernünftig arbeiten kann. Das ärgert mich. Damit werde ich heute mal meinen Verkaufsrep konfrontieren - wenn Emba das nicht bis April nächsten Jahres in den Griff bekommt, friere ich die Entwicklungsumgebung auf den Stand XE3 ein, verlängere meine SA nicht mehr und schaue mich nach mittelfristigen Alternativen um.

*wütendaufstampfundmichschreiendaufdenbodenschmeiß *

Der ganze Mobilkram ist zwar spannend zu verfolgen und ich freue mich, dass Delphi damit eine gewisse Aufwertung erfolgt, ist aber für unser Business relativ uninteressant, da wir Backofficesysteme bauen. Ne Fibu auf dem Smartphone wollte noch niemand haben. Und ne Hotelpreiskalkulation für Veranstalterkataloge ist auf dem Handy auch eher nicht so spannend und würde ob der schieren Datenmenge so manches Inklusivvolumen locker sprengen.

</rant>

So, und nun: aufstehen, Krone richten, weiter geht's: XE 3 wieder klar machen.

[stahli]

Zitat:

Zitat von kretabiker (Beitrag 1281783)

Für XE7-Installation, Einrichtung der Drittkomponenten und Anpassung der eigenen Projekte (denn natürlich hat es in XE 7 im Vergleich zu XE 3 auch wieder Änderungen gegeben, z.B. bei Indy, aber das ist grundsätzlich in Ordnung) plus Ursachensuche für die Memoryprobleme (es war ja nicht auszuschließen, dass der Fehler doch bei mir liegt), habe ich zehn Stunden gebraucht, nur um dann festzustellen, dass ich mit XE7 letztendlich nicht vernünftig arbeiten kann. Das ärgert mich. Damit werde ich heute mal meinen Verkaufsrep konfrontieren - wenn Emba das nicht bis April nächsten Jahres in den Griff bekommt, friere ich die Entwicklungsumgebung auf den Stand XE3 ein, verlängere meine SA nicht mehr und schaue mich nach mittelfristigen Alternativen um.

*wütendaufstampfundmichschreiendaufdenbodenschmeiß *

Ich kann Dir per pm gern Kontaktdaten zu einer Emba-Selbsthilfegruppe schicken. Mir konnte schon etwas geholfen werden. ;-)

[kretabiker]

@stahli: Gerne, mach ruhig - wenn es hilft, meinen Konsum an Beruhigungsmitteln zu reduzieren, immer her damit (mit den Kontaktdaten, nicht den Beruhigungsmitteln) :-) Ich bin gespannt, welche Nasen ich dort wiedertreffe...

[himitsu]

Auf den Delphi-Tagen und ähnlichen Veranstaltungen kannst du mit Einigen auch direkt "reden".

[Stevie]

Es ist auch kein großes Geheimnis, wie man den Delphi Product Manager erreichen kann.

[Der schöne Günther]

Geheimgesellschaften sind überlegen :witch:

[kretabiker]

Genau. Komm auf die Dunkle Seite - wie haben die Schokolade...

[mm1256]

Hallo,

ich hab's auch getan. Von XE2 nach XE7. Beim Compilieren von Projektgruppen kann ich keine signifikanten Unterschiede feststellen. Wegen dem Speicherproblem habe ich mir sowieso bei XE2 schon angewöhnt, vor dem Compilieren den Rechner neu zu starten. Die größte Projektgruppe mit insgesamt 19 Projekten schaffe ich auch mit XE7 auf zweimal, also zuerst 1-9, dann IDE-Neustart, dann 10-19. Damit werde ich auch in Zukunft leben können, weil das ja kein alltäglicher Vorgang ist.

Was nicht direkt zu diesem Thema gehört: Etwa eine Woche hat es gedauert, meine eigenen Komponenten(-Quelltexte) anzupassen und zu aktualisieren bzw. upzudaten. Am längsten (5 Tage) hat sich bei den Externen Components4Developers mit der MemTable-Registrierung gebraucht. Insgesamt gesehen war es jedoch die Mühe wert, allein schon wegen der vielen gefixten VCL-Bugs.

[Bernhard Geyer]

Zitat:

Zitat von mm1256 (Beitrag 1281812)

vor dem Compilieren den Rechner neu zu starten.

:cyclops:

Zitat:

Zitat von mm1256 (Beitrag 1281812)

Die größte Projektgruppe mit insgesamt 19 Projekten schaffe ich auch mit XE7 auf zweimal, also zuerst 1-9, dann IDE-Neustart, dann 10-19. Damit werde ich auch in Zukunft leben können, weil das ja kein alltäglicher Vorgang ist.

Einen kompletten Rebuild macht man besser mit msbuild in der Konsole.

[mm1256]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1281816)

Einen kompletten Rebuild macht man besser mit msbuild in der Konsole.

Das geht in dem Fall nicht, bzw. ist noch umständlicher, weil über eine INC-Datei verschiedene Compilerdirektiven/Schalter/Bedingungen gesetzt/verändert werden müssen. Insofern ist die Projektgruppe eigentlich blos eine Hilfestellung, dass kein einzelnes Projekt beim Rebuild vergessen wird.

[berlinchris81]

Hallo Delphi-Kollegen,

ich habe schon seit langer Zeit das "Out of Memory" Problem beim kompilieren großer (manchmal auch alter) Projekte. Durch viel probieren hab ich herausgefunden, dass wenn ich in den Packages die "LiveBindings" abwähle, ich keine "Out of memory" Fehler mehr habe und die Projekte erfolgreich durchlaufen.

Bin ich ein Einzelfall oder könnt ihr das auch nachvollziehen?

Da ich die LiveBindungen nicht brauche, tut mir das entfernen der Haken nicht weh. Leider kommen die Haken bei jedem Neustart der IDE wieder, aber das muss ich jetzt nur noch selten machen.


Im Anhang ist ein Foto von der veränderten Stelle.


Liebe Grüße

Chris

[Uwe Raabe]

Zitat:

Zitat von berlinchris81 (Beitrag 1282164)

Bin ich ein Einzelfall oder könnt ihr das auch nachvollziehen?

Leider nicht! Ich habe die fünf LiveBindings-Packages mal in der Registry unter Disabled Packages eingetragen, aber trotzdem kann ich den Memory-Error provozieren.

[berlinchris81]

@ Uwe

Vielen Dank für den Versuch, leider doch ein Einzelfall. Versuch wars wert. Ich bleib dran und hoffe auf eine umfängliche Lösung von Embarcadero.

Hast du schon die DDevExtentions probiert? Diese hab ich mit installiert. Vielleicht ist es die Kombination aus beiden Versuchen.


Liebe Grüße aus Berlin

Chris

[Ursa]

Kann man innerhalb der IDE ausschalten, damit das Problem wenigstens nicht so häufig auftritt.





samsung galaxy trend lite schutzhülle

[Alex_ITA01]

@Stevie:

Zitat:

Es ist auch kein großes Geheimnis, wie man den Delphi Product Manager erreichen kann.

Ich habe nur mal so am Rande erwähnt, den Delphi Product Manager auf dieses Speicherproblem bei seinem letzten Online Video Meeting drauf angesprochen bzw eben einfach die Frage gepostet.
Als Antwort kam (wird nicht er beantwortet haben, da er ja das Meeting abhielt):

Frei übersetzt und in eigene Worte gefasst: "Wir haben von Problem von einigen Programmierern erfahren und versuchen das Problem zu identifizieren. Bitte mal die externe Compiliermöglichkeit (in den Delphi Optionen) ausprobieren..."

Ist schon eine Super Sache, wenn man sich eine externe Compiliermöglichkeit einbauen muss, damit man dieses Problem "halbwegs" umschiffen kann. Bei uns geht es übrigens nicht, da ich von TMS irgendwelche Meldungen bekomme, dass *.res Dateien fehlen. Habe mich dann aber nicht weiter mit beschäftigt.

Grüße

[Insider2004]

Marco ist gar kein Produktmanager, sondern ein Marketingmanager. Was er macht, hat überhaupt nichts mit einem PM zu tun. Und ich kenne einige PMs. Ist halt wieder mal der EMBA-way of life.

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1285497)

Marco ist gar kein Produktmanager, sondern ein Marketingmanager. Was er macht, hat überhaupt nichts mit einem PM zu tun. Und ich kenne einige PMs. Ist halt wieder mal der EMBA-way of life.

Und wieso ist er kein Produktmanager? Hast du Informationen was er so den ganzen Tag macht? Oder kennst du ihn nur bei dem was er so nach außen hin sichtbar macht?
Und das du einige PMs kennst heißt noch nicht das diese ihren Job gut machen und Marco nicht. Ich denke Marco macht seinen Job ganz gut. Er macht manche Sachen anders als seine Vorgänger, was aber nicht per Definition schlecht ist.
Und in seine Zeit fallen "nebensächliche" Entwicklung wie Multiplattform-Support, endlich ein brauchbarer BDE-Ersatz aus dem gleichen Hause, ...

[Bernhard Geyer]

In der QC von Emba (RSP-9568) gibts den Tipp die "Borland.Studio.Delphi.DLL" umzubenennen. Damit läuft es scheinbar stabiler.

[Sherlock]

In Marcos Zeit fällt allerdings auch die Behauptung eine beliebig geskinnte Applikation wäre eine voll in Windows integrierte Applikation (http://youtu.be/wJCPx77Z74I?t=4m27s).

Sherlock

[Bernhard Geyer]

Zitat:

Zitat von Sherlock (Beitrag 1285519)

In Marcos Zeit fällt allerdings auch die Behauptung eine beliebig geskinnte Applikation wäre eine voll in Windows integrierte Applikation (http://youtu.be/wJCPx77Z74I?t=4m27s).

Und was ist daran falsch? Designvorgaben für Windows interessieren doch keinen mehr. Viele erfolgreiche Anwendungen (u.a. Browser) scheren sich wenig um die Designvorgaben was z.B. Menü betrifft.
Oder meinst du die Nische Windows RT?

[Der schöne Günther]

Ich habe jetzt nicht auf das Video geklickt, aber vielleicht meint er ja, VCL-Anwendungen als Modern UI-Anwendungen ("Metro") verkaufen zu wollen.

[Sherlock]

OK, so gesehen ist alles gut. Windows ist eh nur noch eine chaotische Ansammlung von mehr oder minder unausgegorenen und verkorksten UI-Vorhaben.
Da lob ich mir doch die strikten und stringenten Designvorgaben in der Apple Welt.

Sherlock