Re: Re: Re: [Zinf-devel] more code cleanups to come
Brought to you by:
kgk,
mayhemchaos
From: Ed S. <ed....@wm...> - 2003-02-05 04:27:34
|
Kristian G. Kvilekval wrote: > On Tue, 2003-02-04 at 17:08, Ed Sweetman wrote: > >>Kristian G. Kvilekval wrote: >> >>>On Tue, 2003-02-04 at 14:08, Ed Sweetman wrote: >>> >>> >>>>Memory wise, the majority of leaks and memory usage occurs in the GTK >>>>code when using that as the UI. I'm going to be focusing on looking for >>>> any mis-use of new and malloc in there. >>>> >>>>This is on top of my global variable cleaning and other such stuff going >>>>on this week. >>> >>> >>>I've seen a lot a memory leaks due to the way playlistitem's are >>>passed around in vectors. This stuff doesn't exist anymore in my >>>version which is almost ready for primetime. A few more days before >>>it goes in, so I would suggest holding off on this. >>> >> >>what's the cause for the holdup? > > > I've got a conference paper I am trying to submit > and there are a few loose ends in the database code. ok. the conference paper is understood. > 1. Repopulate doubles the number of playlists(fixed I think) > 2. Streams are never added or removed > 3. Final vestiges of playlistitems between musiccatalog > and the musicbrowser > 4. Upgrade to latest version of metakit (I've been hounding the > debian packager to update this, but since I've got no response > I am packaging it myself). > > The new code doesn't try to keep the entire music catalog in memory > (building this structure on multi-GB music catalogs was what slowing > the startup). It passes around simple urls and strings that act as keys > for the musiccatalog that will generate playlists items on the fly. > The UI code can always safely delete any playlist item (something it > could not do before). > > Just stuff I never finished the first time around. It's going to > take a couple of days before I can get some freetime to handle these. I'm not sure why the playlist gui fixes are connected to the database fixes. They're completely different objects. If you're not done both then ok, but they should be committed separately because they're unrelated and not very small. generating things on the fly sounds more cpu intensive than just dumping them from memory. On my system, all the code up to reading the playlist on load takes literally less than 1 second; 0.8 seconds. Loading Music Browser takes maybe 1-2 seconds. This is of course if all the songs in your current playlist have been entered into the database. If they aren't in the database because you happened to not run them through the "search for music" crap thing then it will read the file for the metadata. This causes disk IO and can bring loading zinf and the Musicbrowser to a crawl. Rendering the gui is somewhat dependent on the acceleration your X has, so it kind of depends on the video card support you have, but attempting to benchmark that. Why the playlist has any ability to physically alter files i have no idea. The playlist is a highlevel abstract object it should have no low level features so i really hope for zinf's sake that the code that allowed for deleting wasn't in the playlist code and instead it just called a method that told a low level object to delete the file. btw. I'm not saying to rush things really quick now. I'm just wondering why the two patches seem to be linked together since it seems that either one or the other is already done. |