Fast must be the last thing I think of when I use Totem.
I tend to select a bunch of files, and press enter. Totem reads info from all files before it starts to play the first one. This alone makes is very slow when starting it this way.
Threading doesn't seem to have been on there mind when writing it.
It only checks the mime-type of the files to be added, which is at most 1k of data, before starting. That's it.
8 October 2007 at 21:58
Anonymous said...
For what it's worth, the pattern that links all those programs seems to be commercialization... features were added or removed to suit the marketing people.
Totem is hopefully much less susceptible to such forces.
8 October 2007 at 22:51
Anonymous said...
mime-type parsing can be a performance problem because of hard disk seeks, especially if the system has a slow hard disk, is very fragmented, is swapping, etc.
Don't know how much of a real performance hit it's in totem, but anyway... Wouldn't it be better to start playing the first file and read the mime-type for the rest in the background?
I agree about the focus on "movie player" and simplicity of the interface, but at the same time Totem is also may music player of choice (Rhythmbox is overkill for me), so I wouldn't mind a few more music features..
10 October 2007 at 08:58
Anonymous said...
hadess, as someone mentioned before me. This is not the best way to do it.
Simple test, start one song, start up time is 4 seconds, start 100 songs, start up time is 44 seconds on my system...
100 files is not such an uncommon use case.
13 October 2007 at 18:17
Tell me we're not going that way! That's why Totem is just a movie player. I hope we can manage to keep it simple and fast (although the Python plugin support does nothing for its startup speed I've been told).
"Introspection"
8 Comments -
My baseless musing goes straight from IRC and into a blog, I see.
That's efficiency for you. :-D
8 October 2007 at 18:40
Next time, blog it yourself :)
8 October 2007 at 18:53
Fast must be the last thing I think of when I use Totem.
I tend to select a bunch of files, and press enter. Totem reads info from all files before it starts to play the first one. This alone makes is very slow when starting it this way.
Threading doesn't seem to have been on there mind when writing it.
Jochen
8 October 2007 at 21:53
It only checks the mime-type of the files to be added, which is at most 1k of data, before starting. That's it.
8 October 2007 at 21:58
For what it's worth, the pattern that links all those programs seems to be commercialization... features were added or removed to suit the marketing people.
Totem is hopefully much less susceptible to such forces.
8 October 2007 at 22:51
mime-type parsing can be a performance problem because of hard disk seeks, especially if the system has a slow hard disk, is very fragmented, is swapping, etc.
Don't know how much of a real performance hit it's in totem, but anyway... Wouldn't it be better to start playing the first file and read the mime-type for the rest in the background?
9 October 2007 at 07:26
I agree about the focus on "movie player" and simplicity of the interface, but at the same time Totem is also may music player of choice (Rhythmbox is overkill for me), so I wouldn't mind a few more music features..
10 October 2007 at 08:58
hadess, as someone mentioned before me. This is not the best way to do it.
Simple test, start one song, start up time is 4 seconds, start 100 songs, start up time is 44 seconds on my system...
100 files is not such an uncommon use case.
13 October 2007 at 18:17