🚀 go-pugleaf

Stefan Berendes (BERENDES@reze-1.rz.rwth-aachen.de) wrote:
>Wie gross ist ein memory-chunk und welcher overhead steckt in
>seiner Verwaltung?

Äh, kommt drauf an. In welchem Zusammenhang? Warum?

-- 
Heinz Wrobel        Private Mail:   heinz@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email

Heinz Wrobel schrieb in heinz.12je@hwg.muc.de über 'Re: F: Memory hunk größe':

HW> 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?
HW> 
HW> Äh, kommt drauf an. In welchem Zusammenhang? Warum?
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.

HW> 

--
Stefan Berendes

Win95 - It makes a grown man cry!

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?

"Stefan Berendes" <BERENDES@reze-1.rz.rwth-aachen.de> writes:

>Heinz Wrobel schrieb in heinz.12je@hwg.muc.de über 'Re: F: Memory hunk größe':

>HW> 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?
>HW> 
>HW> Äh, kommt drauf an. In welchem Zusammenhang? Warum?
>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.

AllocMem rundet die Anforderungen immer auch Vielfaches von 8 Bytes
auf. Ansonsten gibt es da keinen Overhead.

Allerdings ist der Overhead ja nun bei Dir zu suchen, du musst
Dir ja Pointer auf deine Daten merken. Viele winzige Speicher-
anforderungen sorgen auch fuer die Fragmentierung des freien
Speichers. Am besten forderst Du immer gleich groessere Bloecke
an und verwaltest Dir selbst (oder per MemoryPools).

Salut,
-- 
                                Michael van Elst

Internet: mlelstv@serpens.rhein.de
                                "A potential Snark may lurk in every tree."

In article <32272640@pc7177.dialup.rwth-aachen.de>, "Stefan Berendes" writes:

> 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.

Das  solltest  Du.  Es gehen jeweils 6 Byte drauf, weil der Speicher nur in
8-Byte  Schritten  organisiert  ist.   Außerdem  geht  das  extrem  auf die
Performance.  Glaub mir, ich habe sowas schon mal gemacht.

Nutze lieber die Memory-Pools.