Tom Metro wrote: > 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.)
The recording group thing might help things. > > > 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 It is plain C, but the malloc of memory by the mvpmc library is actually being down by a function that is doing alot more than that, it allocates a structure (anything using the ref_* functions): typedef struct refcounter { #ifdef DEBUG unsigned int magic; struct refcounter *next; const char *file; const char *func; int line; #endif /* DEBUG */ mvp_atomic_t refcount; size_t length; ref_destroy_t destroy; } refcounter_t; Any allocation done with the ref_* functions actually looks like this size wise: void *block = malloc(sizeof(refcounter_t) + len); Where len is the actual len of the string that was asked to be allocated. I don't know exactly how big those elements are on the mvp, refcounter is type unsigned (probably 4), destroy is a void * so likely 4 bytes, and I would expect size_t to also be 4 bytes, so 12 bytes extra are allocated for *EACH* piece of memory used by the ref_* series of functions. All of the program data is allocated via this interface. And I count 24 char * so if all of those were allocated then we are talking about 288 bytes of overhead per program. I have not looked at the code enough to figure out if every char * always has an allocation or not. It looks like if the string has length 0 that an allocation is not done, but I don't know what actually comes back from mythtv so I don't know how many are actually 0 length. > > >> 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. The code is pretty ugly around that stuff. I was looking for a simple way without adding a huge amount of code just to check things. The crude way would be to subtract the last program description char pointer from the first one on and that should give me an idea (on a first load) of how much memory the char *'s use. Roger ------------------------------------------------------------------------- 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/
