Niklas Brunlid wrote:
> I'm up to 1900 movies/episodes on my MythTV backend and moving around
> in the mvpmc menus is an excersice in patience...

Do you have them split up into several recording groups? Do you make use 
of recording group filtering on mvpmc?


> Finally, I wanted to ask if anything came from this discussion.

I proposed modifying mvpmc to filter the data it loaded to reflect the 
recording group filter settings. (Currently it loads everything into 
memory, then applies the filters before displaying the data.) See the 
thread on the dev list for more info. I think this approach will have a 
more immediate benefit and less risk than Roger's approach of trimming 
the size of the data structure. (Which is a good idea too, but I'd do 
that as a later refinement.)


> Did anyone manage to test the proposed changes?

I haven't gotten around to implementing the above yet.

The switch to 0.21 has temporarily relieved the problem for me, as 
there's a slight incompatibility between mvpmc and MythTV resulting in 
some of the messages saying there is new programming data being ignored. 
As a result we aren't getting overlapping reloads happening, which was 
really killing performance before.

So instead I've been playing around with some hacks to get the watch 
list feature (or an equivalent) working.


> If not, how long does it take to get to the point where I can play
> around with the code myself?

I'd say you can get the environment set up in a weekend. There isn't a 
lot of volume to the code, so you should be able to find and comprehend 
the relevant bits fairly easily. As Roger said, there are instructions 
on the wiki for setting up a dev environment.


Roger Heflin wrote:
> If something is allocated to the char *'s then there are a number of
> bytes for the reference counters for overhead for each allocation,
> plus the bytes allocated.

We're talking about plain C, right? Reference counters? You mean the 
malloc overhead? See:

http://ask.metafilter.com/50468/Char-Memory-Allocation-in-C

Which suggests breaking up structs into collections of arrays to be more 
memory efficient (primarily to avoid the padding done by sizeof()).

It also references:
http://en.wikipedia.org/wiki/Sizeof#Implementation
http://en.wikipedia.org/wiki/Malloc#Implementations


> I need to figure out a way to gauge how much memory is being used so I 
> can get an idea of how much is being saved.

If you just want to track memory used for show data, create an 
accumulator variable and add the number of bytes allocated for each show 
record. When the show data is completely loaded, output a debug message. 
This won't include the malloc overhead, though.

Capturing the free system memory before and after loading show data 
might give you a more accurate picture, even if the absolute value is 
less significant. (I seem to recall from the thread on the dev list that 
looking at the absolute free memory number didn't tell you that much, 
due to the kernel eating up memory for buffers or some such.)

  -Tom


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mvpmc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mvpmc-users
mvpmc wiki: http://mvpmc.wikispaces.com/

Reply via email to