drneau.com

drneau · Posted: Wed Jul 11, 2007 2:59 pm Post subject: Memory memory memory

Images and audios.

In v2, I loaded them all into memory upon startup. This required memory.

Some people complained about memory, but I really didn't have a good indication of how much memory images or audios really took up.

When I started working on v3, I added the columns to the component designer to tell you how much space on disk was occupied by your images and audios, so you could get a general idea of how much memory they occupied. I knew that they actually took up more space in memory, but I still didn't know how much.

I was focusing on this the other day and I implemented the code to display "space in memory" rather than "space on disk".

OMG. What did I find? My sample 1552x1164 jpeg that took up about 505KB on disk was taking up 5MB after I loaded it into memory!!! Add a couple dozen or so of those images to your repository and the app will get pretty bogged down...This isn't really under my control...it has to do with image compression for storage vs. how they are handled in memory.

Audios are the same way, although not quite as drastic from what I found.

The reason I went with storing audios and images in memory originally was to make them available to the client...when the client connected I'd fire the audio/image bits over to the client so that it could store them in memory.

Here's my strategy for v3, which appears to work great.
- Images and audios are no longer loaded into memory upon startup. Instead, the components that used to hold them now point to their locations in the repository. My worry about this strategy initially was a delay in playing audios or displaying images, because they would be loaded from disk on demand.
- When an audio is played, a stream is opened to the file. Little memory required. From my tests, there's absolutely no noticable delay from the time I hit "play". I'm really pleased.
- When an image is required to be displayed (on a console, in the library, etc.), it is streamed from disk into a buffer. There's a tiny delay noticable here, but it's sub-second.
- For transmitting to a client, I'm simply going to pick up the *file*, send it to the client and have the client throw it into its repository. Then the client streams from disk the same way the server does.

Just wanted to let you all know performance is taking a leap forward for v3!
_________________
--
Dr. Neau (not a real doctor)
http://drneau.com
http://home.comcast.net/~jneau

Dix · Posted: Wed Jul 11, 2007 10:10 pm Post subject: Re: Memory memory memory

drneau · Posted: Wed Jul 11, 2007 10:55 pm Post subject: Re: Memory memory memory

Dix · Posted: Fri Jul 13, 2007 5:29 am Post subject:

Just in case anyone is curious....

Notice the "size in memory" and "original size on disk" numbers for this JPEG image, which was saved with a compression factor of "20", which is about average for most graphics apps in saving JPEG files.

_________________
- Dix