IndexedString vs. implicit sharing

Milian Wolff mail at milianw.de
Wed Oct 17 19:46:53 UTC 2012


On Wednesday 17 October 2012 20:52:22 Andreas Pakulat wrote:
> Hi,
> 
> On Wed, Oct 17, 2012 at 7:30 PM, Milian Wolff <mail at milianw.de> wrote:
> > Now, who is up for fixing IndexedString to leverage implicit sharing?
> > Sadly I still don't really understand the itemrepository magic.
> 
> I don't understand it either, except that IIRC the main point of
> indexedstring is to have an object which can be serialized very easily
> and quickly to the duchain-disk-representation. In particular in
> memory its just an index into the repository, so extremely memory
> efficient. Adding implicit sharing doesn't gain you much in that case.

Yeah, I'm more speaking about the case where one wants to read/access the full 
version, not just the indexed string.

> > But couldn't we use
> > QString's in there directly?
> 
> That would mean keeping all the bits/bytes for a QString in memory,
> which was the whole reason for dropping their use.

Right. I forgot that kind of. Probably makes the implementation of what I want 
even more complicated or even impossible. Let me give an example here, replace 
QString with KUrl to get the same problem:

      QString qString;
      qString.fill('.', 1000);
      KDevelop::IndexedString indexedString(qString);
      const int repeat = 10000;
      QVector<QString> strings;
      strings.resize(repeat);
      for(int i = 0; i < repeat; ++i) {
        strings[i] = indexedString.str();
        QCOMPARE(qString, strings[i]);
      }

What do you expect that does memory wise? Well, it will hog up more and more 
memory here. That's the Use-Case I'd like to optimize if possible.

> > Maybe that would require us to make IndexedString
> > only operate on QString's but I'd be all for that anyways to increase type
> > safety. But well, food for though...
> 
> What kind of type-safety do you gain by replacing IndexedString with
> QString?

IndexedString has .str() .c_str() .byteArray() and finally .toUrl() - which 
one is the correct one?

DUContext::url() -> should always be a KUrl
Declaration::identifier() -> should alays be a QString

That's what I meant with "type-safety" - probably the wrong word.

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20121017/7ea38bae/attachment.sig>


More information about the KDevelop-devel mailing list