how to obtain the number of songs in the library? Options

[sun4384]

It seems there is no such a method in the library_manager class. Then where should I look for?

[fbuser]

metadb_handle_list items;
static_api_ptr_t<library_manager>()->get_all_items(items);

items.get_count();

[sun4384]

Is it the only way? I think it is inefficient to get the whole list just to get the count.

Actually the reason I want to know the the number of songs in the library is to get the list of all tracks in the library, but instead of calling get_all_items, I choose to do it by pre-allocating memory for the list and calling enum_items to fill up the list.

[Yirkha]

Premature optimization is the root of all evil.

[sun4384]

Well, evil... can you guys be a little less harsh on users? What makes you think this is a premature approach, given I didn't explain the details and you don't know my programming experience?

The original reason for the approach described above is based on my experience with playlist_get_all_items method which is implemented inefficiently. This method calls playlist_get_items, which in turn instantiates enum_items_callback_retrieve_all_items. When instantiated, enum_items_callback_retrieve_all_items resets the length of the target list to zero, and adds tracks one by one to the target list.

Whenever adding a track, the target list has to be expanded by one, which incurs memory allocation for the new target list and copying the tracks to the new new target list. When the length of a playlist is large, like 10000 for example, the incurred overhead causes several seconds of delay.

So, I chose to allocate the space for the target list in advance which can be done in constant time, and go over the tracks and add each to the target list one by one (in fact replacing, by the way). It proved to speed up things in a large margin.

I suggest enum_items_callback_retrieve_all_items class be modified accordingly. Probably the same can be done to enum_items_callback_retrieve_selected_items class.

This post has been edited by sun4384: Jan 2 2009, 18:36

[Yirkha]

I guess other people just use list implementation with better-suited allocator, which then enlarges the memory space e.g. exponentially instead of "one by one". Heck, pfc::list_t<> and metadb_handle_list even use fast_alloc by default unless you tell them otherwise.

[sun4384]

I guess other people just use list implementation with better-suited allocator, which then enlarges the memory space e.g. exponentially instead of "one by one". Heck, pfc::list_t<> and metadb_handle_list even use fast_alloc by default unless you tell them otherwise.

It can't be assumed users will always use fast_alloc for lists. It's not instructed anywhere in the SDK. Even so, the unnecessary allocation and copy has to be taken care of. I have a library of over 60000 tracks (though most of them are duplicates). Still it's 15 times, and the delay is very long.

That's why I originally wanted to do the same workaround for the get_all_items. Actually this method might be implemented with no overhead. I didn't experiment. Anyhow, I think it's good to have a method telling the number of songs in the library.

[Yirkha]

It can't be assumed users will always use fast_alloc for lists. It's not instructed anywhere in the SDK.

Yes, because that would be pretty stupid thing to do. There are several allocation strategies and they should be used adequately in different scenarios. It is assumed that the developers will have enough of that "programming experience" you mentioned earlier to choose them wisely.

Even so, the unnecessary allocation and copy has to be taken care of. I have a library of over 60000 tracks (though most of them are duplicates). Still it's 15 times, and the delay is very long.

How long specifically is a "very long" delay?
Getting track list from a playlist with ~57000 tracks takes less than 7 ms on a Release build here, and my guess would be that most of that time is spent in the O(n) virtual function calls rather than O(log2 n) memory (re)allocations. It's only copying "smart pointers" around anyway.

Anyhow, I think it's good to have a method telling the number of songs in the library.

Maybe. Apart from this preallocation idea of yours (which hasn't been apparently needed even for time-expensive components like Album list or Library search), what else would it be good for?

[sun4384]

The delay in my case was about 10 seconds (not exact though) with around 6xxxx tracks (1.6GHz Intel chip in my case). Regardless of how long the overhead takes, I think the pre-allocation method is the optimal solution in case when the number of tracks to retrieve is known in advance. An advantage not to be missed.

[foosion]

Well, evil... can you guys be a little less harsh on users? What makes you think this is a premature approach, given I didn't explain the details and you don't know my programming experience?

(Emphasis added)
I'm not trying to be mean, but that is precisely what made it look like premature optimization.

[sun4384]

(Emphasis added)
I'm not trying to be mean, but that is precisely what made it look like premature optimization.

I would have to say the way playlist_get_all_items is implemented is premature. Meaningless allocations and copies. I strongly suggest you FIX it.