[openbeos] Re: Tracker icons
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 23 Jul 2005 14:06:00 +0200 CEST
André Braga <meianoite@xxxxxxxxx> wrote:
> 2005/7/22, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> > With lookup, I actually mean "is the attribute there?" I don't mean
> > "read it" (which inherently includes a lookup, too).
> Is it that slow? Won't the VFS vnode cache (assuming there is one!)
> have all the atributes in RAM by then?
It is that slow. Sure the attributes in the small_data section are in
the cache at the time the inode has been read in - but you need an
extra kernel call for each lookup, which is costly as well. The real
problem starts when the file also has attributes outside the small_data
section - because then, the small_data section has to be searched
linearly for the attribute, and then the directory of the attributes as
well.
And I am not talking about opening a folder with 10 entries - I am
talking about opening a folder with 1000 or more entries. Then, all of
a sudden, speed is starting to matter a lot, and the current Tracker is
already much too slow when doing this anyway.
Ever opened a mail folder with 1000 items? I do not like this. And 2
more attribute lookups per file could slow down that process
noticeably.
> > Why not? There are even use cases of this on BeBits (SVG clock via
> > icon).
> In this case, the application would better write straight to the icon
> cache.
Not really, at least not if it just does this a few times per second :)
> > I did, but I can't see how this makes this argument less of a
> > problem -
> > if there is enough space in the small_data section, it will place
> > the
> > data there, if not, it will be put to a separate file; BFS only
> > prefers
> > system attributes over others, it has no understanding of user
> > defined
> > attributes (like what MDR is doing).
> In this case, all that's needed is making the icon cache a system
> attribute?
Yes.
> > And that got me confused. Sure, neither PNG nor SVG icons will fit
> > into
> > the small_data section in most cases.
> Which is why I proposed an internal format Tracker would render the
> icons into and potentially store into the small_data section. I
> called
> it the "icon cache". See?
Yes, but "icon cache" is not really the right term for this, at least
it's very confusing.
Anyway, when we have 32 bit icons, the cached icon should probably be
archived to make sure it'll fit.
> > Now it's my attitude? That's great - I'm just trying to have a
> > reasonable discussion, really.
> I'm really sorry, then. In your first reply to my post I thought your
> language was a little rude. Which is not your regular attitude at
> all.
> So this had upset me a little bit =/
No problem, if I had really understood you correctly, it would indeed
have sounded rude, I agree. But that was not my intention :-)
> > Yes, but you always have to check for custom icons, even if they
> > are
> > absent - and 3 lookups are just too much for this, as you have to
> > do
> > this with every file;
> But it's only for the first time you ever access that file, and
> that's
> the absolutely worst case. Then you'd just do a single lookup for the
> rest of the file's life, on it's icon cache. You could even just copy
> the legacy icon to the icon cache for kicks...
Actually, I think putting the cached icon into every file (even those
without a custom icon) would be much slower and consume tons of memory
over time. But you probably meant custom icons again, while I meant
files without an icon :-)
> > the "no special icon" case is the most common, so
> > you definitely have to optimize for that case first, and only then
> > look
> > into the other performance bottlenecks.
> That's what the MIME database is for, no? And in this case having the
> icons on RAM is a better solution.
The MIME database doesn't avoid the icon lookups.
> > No, that's not obvious, that's wrong. You still have to look, you
> > just
> > won't find anything.
> By your definition of lookup, yes. I meant something different by
> "lookup".
There is not a big performance difference in testing for an attribute
and reading it out (when it's that little). Looking up an item from a
list is usually called "lookup", no matter what you do with this
afterwards.
> > Having differently sized icon attributes is also already a bit more
> > inefficient, because you have to lookup first once to get the size.
> As opposed to what, rendering it JIT? Sorry, but I disagree.
That's not what I meant. I just meant that it's faster to read an
attribute when you know its size beforehand:
char buffer[1024];
node.ReadAttr("large icon", buffer, 1024)
is a lot faster than:
node.GetAttrInfo("large icon", &info);
buffer = malloc(info.size);
node.ReadAttr("large icon", buffer, info.size);
That's why the current method has some advantages.
> > Definitely, though it didn't change my mind :-)
> I always knew your opinions are hard to bend :D :D
I usually try to have a good foundation for them - you just have to
find the right arguments :-)
Bye,
Axel.
Other related posts:
