![]() |
| | Themen-Optionen |
| | Nach oben #2 |
| Erfahrener Benutzer Registriert seit: 29.05.2004
Beiträge: 228
|
Nicht das ich wüsste (eventuell gehts mittlerweile irgendwie, aber als ich das letzte mal gründlich danach gesucht habe ging das auf jeden Fall noch nicht). Zwei Sachen: - es spricht nicht wirklich was dagegen den Heap-Limit schon beim Start hochzusetzen, das ist ja nur ein limit und wird nicht in jedem Fall ausgenutzt, d.h. stört auch nicht - du solltest auch mal gucken wieso dein Programm so viel Speicher braucht, eventuell hast du da was falsch konzipiert. Bei mir war das z.B. so dass ich jede Menge ArrayLists hatte, die alle viel zu viel Speicher verbrauchten bis ich bei jeder trimToSize() aufrief, was gewaltig weniger Speicherverbrauch brachte. MfG Peschmä
__________________ Amazon.de | The Java Trap | Freie Software | Freie Software vs. Open Source | GNU Classpath | GCJ | SableVM "We should forget about small efficiencies, say about 97% of the time: Premature optimization is the root of all evil." - Donald Knuth |
| | |
| | Nach oben #3 |
| Erfahrener Benutzer Registriert seit: 02.02.2005
Beiträge: 525
|
Es ist möglich, dass ein sehr sehr langer (und mit sehr sehr lang meine ich auch wirklich lang, so ab 50000 Zeichen bis unbekannt) StringBuffer in ein JTextArea geschrieben werden muss. Wenn du da weißt, wie ich das verbessern kann ... Immer her damit |
| | |
| | Nach oben #4 |
| Erfahrener Benutzer Registriert seit: 29.05.2004
Beiträge: 228
|
50000 Zeichen, das sind 50 Kilobytes, wie kommst du da auf > 60 MB Speicherverbrauch? (Kann schon sein, wäre aber recht scheisse irgendwie...) MfG Peschmä
__________________ Amazon.de | The Java Trap | Freie Software | Freie Software vs. Open Source | GNU Classpath | GCJ | SableVM "We should forget about small efficiencies, say about 97% of the time: Premature optimization is the root of all evil." - Donald Knuth |
| | |
| | Nach oben #6 |
| Erfahrener Benutzer Registriert seit: 29.05.2004
Beiträge: 228
|
Naja, ist immer noch nur ein halbes Megabyte. Wo gehen die anderen 63.5 hin? Natürlich solltest du am besten mit ensureCapacity() und trimToSize() arbeiten, das bringt Tempo und spart (interne) endlose Rumkopiererei. Aber Speichermässig bringts nicht so viel (zwar, eventuell doch, weill möglicherweise zu einem Zeitpunkt die GC noch nicht lief als StringBuffer gerade ständig intern neuen speicher allokiert). MfG Peschmä
__________________ Amazon.de | The Java Trap | Freie Software | Freie Software vs. Open Source | GNU Classpath | GCJ | SableVM "We should forget about small efficiencies, say about 97% of the time: Premature optimization is the root of all evil." - Donald Knuth |
| | |
![]() |
| Lesezeichen |
| Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1) | |
| Themen-Optionen | |
| |
Ähnliche Themen | ||||
| Thema | Autor | Forum | Antworten | Letzter Beitrag |
| Vserver: Was muss man wissen? | Garnele | Interessante Diskussionsthemen | 26 | 16.09.2006 20:24 |
| Cache für Dateisystem-Abstraktion - wo Implementierung sinnvoll? | pago | Allgemeine Java-Programmierung | 0 | 27.02.2006 11:36 |
| Hilfe, Heap Speicher zu voll... | matt | Desktop-Applikationen und Grafik | 12 | 05.09.2005 14:49 |
| equals() und der "=="-Operator. primitive Datentyp | Ben | Allgemeine Java-Programmierung | 27 | 25.05.2005 02:53 |
| eine Frage über String | punachino | Allgemeine Java-Programmierung | 6 | 19.05.2005 01:14 |