speed improvements (patch)

[Ovidiu Gheorghioiu]

On 10/5/06, Ian Monroe <ian at monroe.nu> wrote:
> On 10/5/06, Martin Aumueller <aumuell at reserv.at> wrote:
> > Thanks for your your on Amarok so far. Yesterday, I actually had the
> > impression that it has become a lot snappier...
> >
> > But the description of your work on AtomicString makes me think that this
> > would render AtomicString pretty much useless: the reason for introducing it
> > was to save memory by holding only one copy of an artist's name instead of
> > one separate for each track. But if you do QDeepCopys, then this advantage is
> > lost. Please correct me if I'm wrong, but if I understood you correctly then
> > I propose to get rid of AtomicString altogether, as it just introduces
> > unnecessary complexity.

That has crossed my mind. But regardless of the deep copies, we still
get an advantage, in that the long-term storage for the playlist items
is actually optimized like this. We do short-term QDeepCopies, but
those disappear fairly fast. I don't know if it's worth the complexity
or not, but there are some savings.

Also, it's actually safer now to do exactText(), etc., from multiple
threads for the AtomicString'ed columns, than it is from the QString
columns, because of the refcounting. Copying the other columns will
still get you, though.

>
> Well or at least use it only precisely where its needed. Why is
> AtomicString used in more then one thread at all? The reason we have
> it is for repetitive artist and album names in the playlist. Many
> string loading operations do occur in threads, but perhaps the QString
> should not become an AtomicString until it gets put into the playlist.

The only uses I see are in the playlist, in the items that have a
chance of repeating a lot.

>
> And yea, in reality Qt3's reference counting makes it virtually
> impossible to not cause some race conditions. :/

Yeah, it's pretty braindead to do this in C++. You can get away with
it in Java, where the thread-safe garbage collector can do the dirty
work for you, but in the absence of that...

My prediction is that they'll get rid of the refcounting, given the
increased emphasis on multi-threading, because of multi-core CPUs.
Then every dev that was told that they can pass QStrings around
instead of const QString &'s, because it's free, will have some work
on their hands.

So on one hand we have some memory savings, and a modest increase  in
thread safety. On the other hand we have deep copies, a global lock,
and extra complexity.

I'd say at least keep it in the tree, as there is potential for
getting rid of the first two drawbacks using e.g. thread-local
storage, if they become problematic.

Regards,
Ovy

>
> Ian Monroe
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>