[Kstars-devel] more on memory usage

[Jason Harris]

I have also ruled out the possibility that there's a memory problem in the 
source/sink data reader implemented for stars.  I replaced that code with a 
simple for-loop through the hipNNN.dat files.  The program size when running 
is the same (109 MB) in this case.

Jason

On Monday 06 October 2003 09:22 am, Jason Harris wrote:
> Hello,
>
> Some further experiments, but unfortunately no new insights.
> I repeated Heiko's experiment of running KStars normally, and again with
> each star added twice in KStarsData::processStar().  The difference in
> memory usage between these two runs was 61 MB, implying 6.1e7/126,000 = 484
> bytes per star.  This is 120 bytes larger than sizeof(StarObject).
>
> I then modified the for-loop in KStarsData::readStarData() so that not all
> of the hipNNN.dat files were read.  I ran three times, reading 0, 1, and 2
> of the star data files:
>
>       0 stars, size = 39.068 MB
> 1000 stars, size = 39.804 MB  (736 Bytes per star)
> 2000 stars, size = 40.452 MB  (692 Bytes per star)
>
> It's interesting that the effective size per star is lower for larger
> numbers of stars.  This could mean that there is some extra data associated
> with the list, but not with individual stars, or that the first 1000 stars
> really do take more memory (because more of them have names, perhaps).
>
> To test this, I repeated the runs reading only 1 and 2 of the hipNNN.dat
> files, but I started at hip021.dat instead of hip001.dat.  None of the
> stars in hip021.dat or hip022.dat are named.  The result:
>
> 1000 stars, size = 39.708 MB  (640 Bytes per star)
> 5000 stars, size = 42.172 MB  (620 Bytes per star)
>
> So, indeed the star names seem to add substantial memory, but we are still
> far above 364 Bytes per star.  Plus, the fact that loading the full list of
> 126,000 stars results in only 484 Bytes per star seems to support the
> conclusion that the extra memory usage is (at least partially) not
> associated with individual stars, but with the aggregate list somehow.
>
> I looked at the star-loading classes (FileSource and KSFileReader) for
> clues, but nothing appeared obviously wrong.  FileSource uses an array of
> QStrings, but these aren't dynamically allocated so that memory should be
> freed when the object is destructed, right?  What's the advantage to using
> an array here, rather than a QStringList?
>
> Jason

-- 
KStars:  A K Desktop Planetarium
http://edu.kde.org/kstars