After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 143223 - [id3demux] Optimize tag reading
[id3demux] Optimize tag reading
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-05-26 17:15 UTC by Johan (not receiving bugmail) Dahlin
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
test script (2.40 KB, text/plain)
2004-06-08 15:47 UTC, Johan (not receiving bugmail) Dahlin 		Details

Description Johan (not receiving bugmail) Dahlin 2004-05-26 17:15:22 UTC 
id3demux takes 17 iterations and almost 200 ms to read a tag from an mp3,
ideally it should be much faster.

This bug is similar to the oggdemux bug 143222.
Comment 1 Benjamin Otte (Company) 2004-06-05 17:03:33 UTC 
In fact that only happens on the first file and is because id3demux does
typefinding and loads typefind plugins. It doesn't happen on subsequent invocations.

Try "gstreamer/tests/spidey_bench /some/music/file.mp3 > output" to see how fast
it really is. That test autoplugs a pipeline and gets the tags. IUt does that
for the same file 10 times. (The redirection is necessary to not get switches to
the terminal in between and get real results.) It takes around 17.5ms here,
which IMO is fine.

Note that the number of iterations is irrelevant, because it just displays the
granularity of the plugins involved. More iterations = higher granularity = better.

I'm closing this as invalid.
Comment 2 Johan (not receiving bugmail) Dahlin 2004-06-08 15:47:50 UTC 
Created attachment 28475 [details]
test script

Script used to test
Comment 3 Johan (not receiving bugmail) Dahlin 2004-06-08 15:50:25 UTC 
Sometimes it's still unacceptably slow (50 ms) and sometimes it's fast (2 ms).
It shouldn't really take more than a couple of ms to read the tags. I can't see
why any expensive computations should be performed.

Re-opening bug (until I have a reliable way of fetching tags).

Sample output of a directory with 2 oggs and a bunch of mp3s:

ogg (5) iterating (1 iters) took 314.5 ms
mp3 (6) iterating (17 iters) took 76.4 ms
ogg (4) iterating (1 iters) took 0.9 ms
mp3 (7) iterating (17 iters) took 1.4 ms
mp3 (7) iterating (17 iters) took 47.3 ms
mp3 (7) iterating (17 iters) took 1.5 ms
mp3 (7) iterating (17 iters) took 47.8 ms
mp3 (6) iterating (17 iters) took 1.5 ms
mp3 (6) iterating (17 iters) took 1.5 ms
mp3 (6) iterating (17 iters) took 47.5 ms
mp3 (6) iterating (17 iters) took 48.4 ms
mp3 (6) iterating (17 iters) took 47.6 ms
mp3 (6) iterating (17 iters) took 48.2 ms
mp3 (7) iterating (83 iters) took 49.1 ms

(all mp3 songs have id3 and id3v2 tags)
Comment 4 Benjamin Otte (Company) 2004-06-23 00:17:57 UTC 
Yes, I know that task switches to gnome-terminal to print out that line are
slow. As are hard disk accesses.

closing again.


After running that thing with redirection into a file and the files cached in
RAM, I get _repeatedly_ output like this (all mp3s, had to remove tag counting
because of "TypeError: lists are not supported"):

mp3 (0) iterating (17 iters) took 478.7 ms
mp3 (0) iterating (17 iters) took 2.2 ms
mp3 (0) iterating (17 iters) took 2.2 ms
mp3 (0) iterating (17 iters) took 2.2 ms
mp3 (0) iterating (17 iters) took 2.2 ms
mp3 (0) iterating (17 iters) took 2.2 ms
mp3 (0) iterating (17 iters) took 2.2 ms
mp3 (0) iterating (17 iters) took 2.5 ms
mp3 (0) iterating (17 iters) took 2.3 ms
mp3 (0) iterating (17 iters) took 2.2 ms
mp3 (0) iterating (17 iters) took 2.3 ms
mp3 (0) iterating (17 iters) took 2.3 ms