Article View: de.comp.sys.amiga.tech
Article #1301Re: F: Memory hunk größe
From: Matthias Fleischer
Date: Mon, 23 Oct 1995 11:06
Date: Mon, 23 Oct 1995 11:06
24 lines
1501 bytes
1501 bytes
In article <32272640@pc7177.dialup.rwth-aachen.de>, Stefan Berendes <BERENDES@reze-1.rz.rwth-aachen.de> wrote: >HW> >Wie gross ist ein memory-chunk und welcher overhead steckt in seiner >HW> >Verwaltung? sizeof(struct MemChunk) == 8 - das ist auch genau die Granularitaet der Speicherverwaltung. Beim Allozieren wird im worst-case jedesmal die gesamte Liste der freien Speicherblocke durchgegangen. Der CPU-Overhead ist also ziemlich deftig. >Weil ich fuer eine Datenbank z.Zt. etwa 20000 74 Byte lange >Datensaetze habe, die ich zur Zeit einzeln mit AllocMem >allokiere. Wenn da jedesmal einige Bytes draufgehen, muss ich das >ganze halt etwas anders organisieren. Bytes gehen eigentlich kaum drauf, aber CPU-Zeit. Nimm doch Pools (kann man wenn man will auch selber welche bauen - siehe Allocate(), Deallocate().) dann ist das Problem etwas weniger wild. Und wenn die Datensaetze alle genau gleich lang sind, ist eine eigene Verwaltung sogar noch schneller. Matthias -- Ever noticed that %=0/0=NaN?
Technical Details
Message-ID:
<46fsve$1d9s@info4.rus.uni-stuttgart.de>Path:
arc1-ca.pugleaf.net!news.uni-stuttgart.de!fleischrReferences:
<32272627@pc7177.dialup.rwth-aachen.de> <heinz.12je@hwg.muc.de> <32272640@pc7177.dialup.rwth-aachen.de>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!news.uni-stuttgart.de!fleischr From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Newsgroups: de.comp.sys.amiga.tech Subject: Re: F: Memory hunk größe Date: 23 Oct 1995 11:06:22 GMT Organization: None. I'm not organized at all. Message-ID: <46fsve$1d9s@info4.rus.uni-stuttgart.de> References: <32272627@pc7177.dialup.rwth-aachen.de> <heinz.12je@hwg.muc.de> <32272640@pc7177.dialup.rwth-aachen.de> NNTP-Posting-Host: sunserv.izfm.uni-stuttgart.de