🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: de.comp.sys.amiga.tech
Article #1301

Re: F: Memory hunk größe

#1301
From: Matthias Fleischer
Date: Mon, 23 Oct 1995 11:06
24 lines
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!fleischr
References: <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