[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Kpresenter hogs memory
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2006-11-17 12:53:34
Message-ID: 200611171353.39812.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 17 November 2006 12:49, Subhashis Roy wrote:
> Hello,
>
> After going through 'First look: KOffice 1.5, part 1: The major
> applications' in http://www.linux.com/article.pl?sid=06/03/01/1550241, I
> was trying with Kpresenter-1.5 Beta 1 on Debian Sarge. However, I was
> astonished to find that an Openoffice '.odp' presentation file of 5 MB
> in size takes about 481 MB of 'non-swapped physical memory' (RES in
> 'top') after loading it. Since this was a Beta release, I downloaded the
> KDE Live CD with Kpresenter-1.6 and ran it using Qemu with an allocated
> memory of 384 MB through 'kqemu'. I was surprised to find that it took
> 280 MB of memory (RES in 'top') in trying to open that file. Then a
> message something like ..no memory left was shown on that screen and no
> response.  On the other hand, in opening that 5 MB '.odp' file,
> 'openoffice-2.0.3' took 64 MB of memory.

Yes, we know that the way we currently load documents is not memory efficient.  
As Ariya has said, we're (or rather, he is) working on it. And while there 
are definitely other places where memory usage could be more efficient, top 
is the wrong tool to measure. Don't use top top measure memory usage under 
linux. It is useless.

> I also created a small presentation with Kpresentation. I found that
> when the document size is ~100 KB, it taken only about ~40 MB, but once
> I included an 1 MB 'jpg' image, it started taking >65 MB. It appears
> that there is something very badly implemented in handling memory with
> Kpresenter.

How big is your jpg image once converted to bmp? When I take a sample 1.3 mb 
jpeg image and convert it to bmp (which is as close as possible to the 
necessary in-memory representation of images, that is, just the pixels), it 
grows to 29 MB. Now, if that image is stored inside the document it'll make 
memory usage grow with 29 mb. Which is the difference you mention.
>
> I was also surprised to find that the KDE Live CD takes about 250 MB of
> total memory when just a 'Konsole' is started after booting with Qemu.
> Whereas, I can run Debian Sarge with 'fvwm95' as Window manager and a
> few Xterms comfortably with just using 64 MB of RAM.

Yeah, I remember those days, too. fvwm, couple of xterms... Had to have 
xclock! It all fitted in 8 mb of memory, but I couldn't run Netscape for 
webbrowsing. Of course, there is rather a lot that that setup didn't do, like 
webbrowsing, image editing, wordprocessing, chatting, dvd burning, truetype 
font rendering, postscript font rendering and more. Here's a good article for 
you to read on the topic: http://ktown.kde.org/~seli/memory/.

> Linux was designed in a way which was mostly non-GUI based and makes
> efficient usage of memory. However, it appears to me with a GUI based
> approach (I donot see anyrhing wrong in using this approach efficiently)
> of KDE, they are taking the Linux to the other side of inefficient usage
> of memory. I do like Linux and use it fully for my academic work as a
> scientist from 1996 with the then Slackware distribution. I was thinking
> to use KDE but coming across this inefficient usage of memory suggests
> me of not using it at all.

Linux, like all Unix systems have always been comparatively memory-hungry: 
it's only because all the stuff you could do with Windows 95 wasn't possible 
with Linux/X11 in 1995 that Linux got a reputation for frugality with systems 
resources.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]