Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: how to obtain the number of songs in the library? (Read 6128 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

how to obtain the number of songs in the library?

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

how to obtain the number of songs in the library?

Reply #1
metadb_handle_list items;
  static_api_ptr_t<library_manager>()->get_all_items(items);
 
  items.get_count();

how to obtain the number of songs in the library?

Reply #2
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.

how to obtain the number of songs in the library?

Reply #3
Premature optimization is the root of all evil.
Full-quoting makes you scroll past the same junk over and over.

how to obtain the number of songs in the library?

Reply #4
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.

how to obtain the number of songs in the library?

Reply #5
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.
Full-quoting makes you scroll past the same junk over and over.

how to obtain the number of songs in the library?

Reply #6
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.

how to obtain the number of songs in the library?

Reply #7
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?
Full-quoting makes you scroll past the same junk over and over.

how to obtain the number of songs in the library?

Reply #8
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.

how to obtain the number of songs in the library?

Reply #9
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.

 

how to obtain the number of songs in the library?

Reply #10
(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.