comp.lang.ada
 help / color / mirror / Atom feed
From: mhamel_98@yahoo.com
Subject: Re: Memory Useage
Date: Mon, 11 Jun 2007 08:28:15 -0700
Date: 2007-06-11T08:28:15-07:00	[thread overview]
Message-ID: <1181575695.810415.259520@w5g2000hsg.googlegroups.com> (raw)
In-Reply-To: <466a398f$0$8390$39db0f71@news.song.fi>

On Jun 9, 1:25 am, Niklas Holsti <niklas.hol...@nospam.please> wrote:
> mhamel...@yahoo.com wrote:
> > Hello c.l.a.  Another question, I have a program that stores data on
> > the disk using sequential_io.  When I later read that data into an
> > array, the memory growth after ingesting a file is much much larger
> > than the disk footprint.  A file that takes 26.8MB on disk (over 134k
> > records) causes the program to swell by over 600MB!  Holy bloatware.
> > A short overview of what I'm trying to do - each sequential_io data
> > file has an associated header file with stuff like number of records,
> > etc.  The header is read, and an array is then created based on how
> > many records are said to be in the data file.  The data file is then
> > read, sticking a node into the array.  Some abbreviated code below,
> > the spec:
>
> > generic
> >   type Node_Type is private;
> > package Node_Manager is
>
> >   package Seq is new Sequential_Io (Node_Type);
>
> >   type Node_Array is array (positive range <>) of Node_Type;
> >   type Node_Ptr is access Node_Array;
>
> Is the actual type for Node_Type a record type with variants? If so, is
> the size of the largest variant much larger than the size of the most
> common variants? I don't know about ObjectAda, but in GNAT the
> Node_Array would have a size that lets you store the largest variant in
> every array element, while the Node_Type objects stored in the
> sequential_io file probably use only as much file-space as the actual
> variant of each object requires.
>
> The solution in GNAT would be to allocate storage for each Node_Type
> object separately and have an array of accesses:
>
>     type Node_Ptr is access Node_Type;
>     type Node_Array is array (positive range <>) of Node_Ptr;
>     type Node_Array_Ptr is access Node_Array;
>
> This increases memory overhead by allocating more blocks from the heap,
> but it may reduce the overall memory requirement if the largest variant
> of Node_Type is much larger than the average variant.
>
> --
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .- Hide quoted text -
>
> - Show quoted text -

Hi Niklas, no variant records, that's the first question a few other
people asked as well though!

Anyhoo, good news, bad news.  Good news is, this bit of code isn't the
source of the bloat.  The bad news is what is causing it is an
instantiation (several instantiations actually) of a generic Double-
Linked-List package.  Well, back to the drawing board...




      reply	other threads:[~2007-06-11 15:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-08 20:38 Memory Useage mhamel_98
2007-06-09  0:43 ` Adam Beneschan
2007-06-09  3:09   ` mhamel_98
2007-06-09  5:25 ` Niklas Holsti
2007-06-11 15:28   ` mhamel_98 [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox