45 lines
1.8 KiB
Plaintext
45 lines
1.8 KiB
Plaintext
From: aaron_watters at my-dejanews.com (aaron_watters at my-dejanews.com)
|
|
Date: Mon, 19 Apr 1999 19:50:52 GMT
|
|
Subject: Memory and swapping question
|
|
References: <371B5ED8.A9C82170@appliedbiometrics.com>
|
|
Message-ID: <7fg1ep$t5s$1@nnrp1.dejanews.com>
|
|
Content-Length: 1487
|
|
X-UID: 557
|
|
|
|
In article <371B5ED8.A9C82170 at appliedbiometrics.com>,
|
|
Christian Tismer <tismer at appliedbiometrics.com> wrote:
|
|
> due to a question which came up in the tutor list, I'd like
|
|
> to ask if somebody can explain the following:....
|
|
|
|
<chomp><chomp>timings on making huge lists of integers...
|
|
|
|
> On my system, creation takes about 10 times as for big/2,
|
|
> this is ok. But the del takes at least three times as long.
|
|
> Besides the fact that integers are never really disposed but
|
|
> build up a freelist, why is deletion so much slower now?
|
|
|
|
Could be wrong, but this may be a case of a famous database
|
|
problem. The OS (typically) swaps out pages by picking the "least recently
|
|
used" page, but when you are decreffing (scanning) a HUGE list of sequentially
|
|
allocated objects this guarantees that the page you need next will
|
|
be swapped out by the time you get to it. Yikes! Allocation is faster
|
|
because you are really only "paging things out" (the first time)
|
|
and the write to the disk can be buffered until the disk is
|
|
ready, allowing the program to proceed (?I think?).
|
|
|
|
This is one reason why Oracle and Sybase, etc, like to do their own
|
|
memory and disk management ("gimme them sectors -- don't need no
|
|
g.d. filesystem, thanks!"). Just a guess, but a not completely
|
|
uneducated one.
|
|
-- Aaron Watters
|
|
===
|
|
stop procrastinating tomorrow.
|
|
|
|
|
|
-----------== Posted via Deja News, The Discussion Network ==----------
|
|
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
|
|
|
|
|
|
|
|
|