...tja, meine alte Kiste ist ja mit 256MB RAM nicht mehr die modernste, dennoch frage ich mich, warum z.B. eine Entwicklungsumgebung wie das CodeComposerStudio damit nicht vernünftig arbeiten will. Systemvoraussetzungen sind angeblich mindestens 1GB RAM. Entsprechend ruckelig arbeitet das Programm auch auf meinem Rechner... nur mal im Ernst ... WARUM ZUM TEUFEL BRAUCHT EIN BESSERER TEXTEDITOR PERMANENTEN SOFORTZUGRIFF AUF 1.000.000.000 BYTE AN DATEN ??? Das, was ich am Ende in meinem uC flashen will ist ein LED-Blinkprogramm und kein 3D-Hologramm... Lernen Programmierer heute nicht mehr mit Speicher sinnvol umzugehen?
Irgendwie scheint das was ich vor ein paar Jahren im ersten Semester C++-Grundkurs gelernt habe out zu sein. Wenn man dynamische Speicher verwendet, muss man diese Anfordern und wieder freigeben. Nur seltsamer Weise scheint das freigeben des Speichers in Vergessenheit geraten zu sein. Z.B Altium Designer.... ohne regelmäßiges Neustarten müsste ich wohl aller 2 Stunden einen RAM-Rigel nachlegen
Ja auch bei Altium Designer stösst mir das mitlerweile tierisch auf. Technisch gesehn können die Programme nur wenig mehr Algotithmen als vor einigen Jahren. Der Speicheraufwand dafür ist aber überexponentiell gestiegen. Mein Fazit: Neuer Rechner noch heute bestellt...
Naja, der bessere Texteditor kennt ja alle Funktionen und Variablen in den verschieden Datein, muss sämtliche Funktionsprototypen aus Standard libraries und eigenen libraries im Speicher halten, soll wenn möglich endloses undo haben, alle Schlüsselwörter kennen, um die zu highlighten, und bestenfalls sollte der noch intern ein baumdarstellung des codes haben, um Funktionen kollabieren zu lassen und die Klammerung prüfen zu können. Und wenn man von einer Datei oder einem Projekt zum anderen wechselt, sollte der nicht endlos laden, bis der alle Daten und Darstellungen aufgebaut hat. Ich würde damit wahrscheinlich auch nicht auf 1GB kommen, aber ein paar 100MB bei größeren Projekten erscheinen mir schon möglich. Vorallem weil in den Systemanforderungen ja auch das Betriebssystem und der Window Manager mit drin sind. (Oder steht auf der Packung 1GB + was auch immer das BS braucht?)
Dnag schrieb: > Nur seltsamer > Weise scheint das freigeben des Speichers in Vergessenheit geraten zu > sein. Das kommt auch zum Teil von "moderneren" Sprachen her. Wenns wie bei Java einen Garbage Collector gibt, kümmern sich die Leute schon aus Bequemlichkeit nicht mehr ums freigeben. Über einen Bekannten in der Softwareentwicklung hör ich immer wieder, wie dort teils mit Speicherplatz umgegangen wird. Dass z.B. ein 2 GB RAM nicht ausreicht, da sich das Javaprogramm erstmal sicherheitshalber 1,5 GB Ram reserviert... Aber ist wohl überall dasselbe, Rechenleistung ist billig und scheinbar im Überfluss vorhanden, daher wird nicht viel Wert auf Sparsamkeit gelegt.
Floh schrieb: > Rechenleistung ist billig ... und Intelligenz teuer, damit könnte man sparsamer programmieren.
Mit Java kenn ich mich jetzt nicht aus, aber kann man da überhaupt "per Hand" Objekte freigeben? (Der reservierte RAM ist ja eigentlich uninteressant, interessant wirds erst wenn der Working-Set böse groß ist)
bluppdidupp schrieb: > Mit Java kenn ich mich jetzt nicht aus, aber kann man da überhaupt "per > Hand" Objekte freigeben? Man kann den Garbage Collector explizit aufrufen. So elegant wie ein "delete object_ptr; object_ptr = NULL;" ist das halt nicht ;-)
Mark Brandis schrieb: > Man kann den Garbage Collector explizit aufrufen Sollte man aber nicht tun... Wird zumindest als "bad style" angesehen. Man gibt Speicher einfach frei indem man die Referenzen auf das Objekt entfernt. Mark Brandis schrieb: > So elegant wie ein "delete object_ptr; object_ptr = NULL;" > ist das halt nicht ;-) Ganz besonders "elegant" ist es vor allem wenn dann irgendein schusselkop (meist man selbst) dann auf einen NP läuft o.ä. und das Programm mit 'nem Coredump abraucht... da ist dann immer die Freude gross :) Floh schrieb: > sicherheitshalber 1,5 > GB Ram reserviert Reservierter Speicher != belegter/genutzter Speicher.
Läubi .. schrieb: > Ganz besonders "elegant" ist es vor allem wenn dann irgendein > schusselkop (meist man selbst) dann auf einen NP läuft o.ä. und das > Programm mit 'nem Coredump abraucht... da ist dann immer die Freude > gross :) Da ist es natürlich viel besser, wenn das Java-Programm mit einer null-pointer-Exception abbricht, obwohl es da doch gar keine Pointer gibt. > Floh schrieb: >> sicherheitshalber 1,5 >> GB Ram reserviert > > Reservierter Speicher != belegter/genutzter Speicher. Um das zu erreichen, machen Betriebssysteme "lazy allocation" und "memory overcommitment". Das bedeutet im Klartext, daß bei der Allokation das System erstmal nur so tut, als ob da Speicher allokiert würde, und daß es auch mehr Speicher "bweilligt", als eigentlich überhaupt (inklusive Auslagerung) verfügbar. xUnd wenn ein Programm dann doch mal den Speicher braucht, der dann aber gar nicht exisitert, bekommt es deshalb vom System keinen gescheiten Fehler schon bei der Allokation zurück, sondern wird dann später beim Zugriffsversuch einfach abgeschossen. Und das alles nur, weil so viele Programme eben massig Speicher allokieren, den sie gar nicht brauchen.
Rolf Magnus schrieb: > Da ist es natürlich viel besser, wenn das Java-Programm mit einer > null-pointer-Exception abbricht, obwohl es da doch gar keine Pointer > gibt. Deshalb ja die Beschwerde des Interpreters: null pointer Er will endlich welche haben!
Rolf Magnus schrieb: > wenn das Java-Programm mit einer > null-pointer-Exception abbricht Das hat aber nix mit Speicher freigeben zu tun sondern ist schlicht ein Programmfehler, und es heißt noch lange nicht, dass das Programm dann abbricht. Rolf Magnus schrieb: > obwohl es da doch gar keine Pointer gibt Ja eigentlich müßte es wohl NullObjektDereferenzierungsException heißen, aber das war dem Namensgeber wohl entweder zu lang oder er war zu sehr C verhaftet ;) Rolf Magnus schrieb: > Und das alles nur, weil so viele Programme eben massig Speicher > allokieren, den sie gar nicht brauchen. Ich wollte auch nur anmerken, dass nur weil ein Program Speicher reserviert, das nicht heißt, dass das BS diesen die ganze Zeit im RAM hält. Bei Java gibt es auch noch intern eine Beschränkung, dass man beim Progammstart festlegt wievielt Speicher die VM maximal reservieren darf (und übrigens zumindest bei den VMs die ich kenne auch wieder freigibt wenn nicht mehr benötigt). Und dieser Wert wird von "faulen" Programmierer auch gerne etwas höher gesetzt. Ich wollt jetzt hier auch keine Riesen Diskussion anstoßen erst recht nicht nach dem !quallifiziertem" Eingangsposting...
Floh schrieb: > Über einen Bekannten in der Softwareentwicklung hör ich immer wieder, > wie dort teils mit Speicherplatz umgegangen wird. Dass z.B. ein 2 GB RAM > nicht ausreicht, da sich das Javaprogramm erstmal sicherheitshalber 1,5 > GB Ram reserviert... Das kommt auch mit dadurch, daß viele Programmierer wohl noch nicht mitbekommen haben, daß es Multitasking gibt und daher ihr Programm evtl. nicht das einzige ist, das gerade auf dem Rechner läuft. > Aber ist wohl überall dasselbe, Rechenleistung ist billig und scheinbar > im Überfluss vorhanden, daher wird nicht viel Wert auf Sparsamkeit > gelegt. Läubi .. schrieb: > Rolf Magnus schrieb: >> wenn das Java-Programm mit einer >> null-pointer-Exception abbricht > > Das hat aber nix mit Speicher freigeben zu tun sondern ist schlicht ein > Programmfehler, Das ist in C aber auch so. > und es heißt noch lange nicht, dass das Programm dann abbricht. Wie oft kommt es denn vor, daß so eine Exception abgefangen und auf sinnvolle(!) Art darauf reagiert wird? Wie du schon sagst, resultiert die Exception ja aus einem Programmfehler, der gar nicht hätte auftreten sollen. Und der Fehler ist ja schon passiert, wenn man in den Exception-Handler kommt.
>Systemvoraussetzungen sind angeblich mindestens 1GB RAM.
solche Rechner bekommt man inzwischen nicht mal mehr für 1€ vekauft,
weil das keiner haben will..
für einen (professionellen=ich will Geld verdienen) Programmierer stellt
sich die frage also tatsächlich kaum, ober er eine Stunde investieren
soll, um ein paar Byte zu sparen..
ausserdem: was würdest du angeben ?
ich find 1GByte als "Systemvoraussetzung" schon ziemlich mutig..
(ohne sonst irgendwelche angaben)
das reicht ja bei einigen "Betriebssystemen" schon nicht, wie sollen da
dann noch Programme laufen ;-)
Speicherverschwendung schrieb: > WARUM ZUM TEUFEL BRAUCHT EIN BESSERER TEXTEDITOR... braucht er nicht, schaust du hier: http://www.mikrocontroller.net/articles/AVR_CP/M Editoren iwe EDIT, oder sogar Wordstar außerdem noch: BDS-C, Modula-2, ASM, BASIC, COBOL, PASCAL, Forth, FORTRAN-77,...
Rolf Magnus schrieb: > Wie oft kommt es denn vor, daß so eine Exception abgefangen und auf > sinnvolle(!) Art darauf reagiert wird? kommt drauf an, eine RuntimeException sollte man natürlich nur fangen wenn man auch was damit anfängt, es ist aber durchaus üblich das EventQuellen in etwa dieser Art implementiert werden:
1 | foreach(Handler handler: handlers) { |
2 | try { |
3 | handler.someThingChanged(event); |
4 | } catch(RuntimeException e) { |
5 | System.err.println("Dispatching event failed: "+e.getMessage()); |
6 | e.printStackTrace(); |
7 | }
|
8 | }
|
Das führt dann dazu das falls der Handler Fehler enthält nicht abgebrochen wird, und andere (fehlerfreie) Handler trotzdem ausgeführt. Auch wird normalerweise nur der aktuelle ThreadContext abgebrochen falls man da schlampt...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.