Discussion:
[Development] QStringRef conversion functions
Keith Gardner
13 years ago
Permalink
I was wondering if there would be a possibility of getting some of the conversion functions that are in QString implemented in QStringRef (toInt, toFloat, etc...). The reasoning behind this is that I am using the QXMLStreamReader to parse an XML file with over 88,704 floating point values. I am trying to improve the speed at which the file is parsed and I believe one of the bottlenecks is taking an attribute of QStringRef and copying its data into a QString in order to convert to a float. I would prefer that the copy never happen but that would require some more intelligence be added into the QStringRef class.

Would this be possible to add this in time for the Qt 5.0 release? If not, would it be possible to add this for Qt 5.1 release?

Keith Gardner
Software Engineer
Zebra Imaging
9801 Metric Blvd., Suite 200
Austin, TX 78758
Girish Ramakrishnan
13 years ago
Permalink
Hi,

On Mon, Jun 11, 2012 at 11:38 AM, Keith Gardner
...
I am tempted to say it's 5.1 material but it would be nice to see how
much gains you are getting out of these new apis and how intrusive the
new code is. Can you push your change to gerrit ?

Thanks,
Girish
Thiago Macieira
13 years ago
Permalink
...
We might be able to remove QStringRef before Qt 5.0 and replace it with plain
QString.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
Konstantin Ritt
13 years ago
Permalink
...
That is what I'd love to see in 5.0.
Making sub-QStrings as cheap as QStringRef currently is would give us
quite significant performance boost in some common use-cases. Then,
QStringRef definitely should go.

Konstantin
a***@nokia.com
13 years ago
Permalink
Hi,
...
Won't a QString always require an allocation for the d-ptr? So it'll never be quite as cheap as QStringRef.

Cheers,

Aaron
Thiago Macieira
13 years ago
Permalink
Post by a***@nokia.com
Won't a QString always require an allocation for the d-ptr? So it'll never
be quite as cheap as QStringRef.
Not exactly.

A QStringRef points to an existing QString. Therefore, if we take a QString
that is pointing to a substring of an existing QString, the d-ptr is already
allocated. The new QString would be as cheap as the current QStringRef.

The issue we'll run into is that a substring could be "holding hostage" a huge
chunk of memory.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
a***@nokia.com
13 years ago
Permalink
Hi,
Post by Thiago Macieira
Post by a***@nokia.com
Won't a QString always require an allocation for the d-ptr? So it'll never
be quite as cheap as QStringRef.
Not exactly.
A QStringRef points to an existing QString. Therefore, if we take a QString
that is pointing to a substring of an existing QString, the d-ptr is already
allocated. The new QString would be as cheap as the current QStringRef.
How does that work? Where do you store the substring's offset and length data?

Cheers,

Aaron
Post by Thiago Macieira
The issue we'll run into is that a substring could be "holding hostage" a huge
chunk of memory.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Thiago Macieira
13 years ago
Permalink
Post by a***@nokia.com
Post by Thiago Macieira
A QStringRef points to an existing QString. Therefore, if we take a
QString that is pointing to a substring of an existing QString, the
d-ptr is already allocated. The new QString would be as cheap as the
current QStringRef.
How does that work? Where do you store the substring's offset and length data?
In the QString.

You might have missed the other thread where we're discussing moving the data
pointer and length to the main class in QString, QByteArray and QVector.

I've begun doing that work, but turns out that there's a LOT of code to get
ported, starting with moc.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
André Pönitz
13 years ago
Permalink
Post by Thiago Macieira
Post by a***@nokia.com
Won't a QString always require an allocation for the d-ptr? So
it'll never be quite as cheap as QStringRef.
Not exactly.
A QStringRef points to an existing QString. Therefore, if we take a
QString that is pointing to a substring of an existing QString, the
d-ptr is already allocated. The new QString would be as cheap as the
current QStringRef.
The issue we'll run into is that a substring could be "holding
hostage" a huge chunk of memory.
This is not much different from current usage. The difference would
be the "outer" string contents being re-allocated as result of
non-const operations on it. This "works" (to a certain degree...)
with QStringRef, but wouldn't with "cheap substrings".

However, I still have to see such a "mutable" case in practice.
The QStringRef uses I am aware of are very limited in scope,
often just saving a single copy of (parts of) the owning strings.
Nice, but not even close to the potential of "cheap substrings".

Andre'

André Pönitz
13 years ago
Permalink
Post by a***@nokia.com
That is what I'd love to see in 5.0. Making sub-QStrings as cheap
as QStringRef currently is would give us quite significant
performance boost in some common use-cases. Then, QStringRef
definitely should go.
Won't a QString always require an allocation for the d-ptr? So it'll
never be quite as cheap as QStringRef.
Depends on the implementation.

One suggestion was to store "enough" data inside the object proper to
not require "external" data fields for those cases. The amount of data
needed depends on the operations one wants to support. As far as I can
see, two pointers + one int (one direct pointer to char data, one
pointer to auxillary data like refcount, flags, alloc, one int for size)
are enough for "everything" including fast direct accesse to the
character array and size. But that's fat (20 byte on 64bit, 12 on 32).
Too fat even. 16/8 would be _much_ better.

If someone came up with a clever idea to _safely_ replace the auxiliary
pointer by a 32 bit offset to the data pointer there is even some hope
for a _really_ good solution, at least for 64 bit....

Andre'
Keith Gardner
13 years ago
Permalink
Sorry to backtrack this thread, but I have some performance information. Just FYI, I haven't made any code changes to Qt, yet.

To give some background information, I am parsing a single xml file with 88,704 floating point values using the QXmlStreamReader. I am running in Windows 7 x64 and am using an SSD to store the file. My compiler is Visual Studio 2010 with a Win32 configuration.

I would take the QStringRef for the argument, convert it to a string using the toString() function and then use toFloat().

This method would parse the entire document in 608 milliseconds in release mode.
stringRef.toString().toFloat()
Changing that code to use wcstod on the QStringRef resulted in parsing the document in 467 millesconds.
wcstod((const wchar_t*)stringref.unicode(),0);

In debug mode, this goes from 2814 milliseconds down to 1850 milliseconds.

I would say that there is a big payout with changing what we currently have.

Thanks,
Keith

-----Original Message-----
From: Girish Ramakrishnan [mailto:***@forwardbias.in]
Sent: Monday, June 11, 2012 4:55 PM
To: Keith Gardner
Cc: ***@qt-project.org
Subject: Re: [Development] QStringRef conversion functions

Hi,

On Mon, Jun 11, 2012 at 11:38 AM, Keith Gardner
...
I am tempted to say it's 5.1 material but it would be nice to see how
much gains you are getting out of these new apis and how intrusive the
new code is. Can you push your change to gerrit ?

Thanks,
Girish
Girish Ramakrishnan
13 years ago
Permalink
Hi Keith,
Yes, it makes sense to add QStringRef::toInt/Float/Double. The entire
point of QStringRef was to make things faster and having those apis
will definitely be an improvement.

Girish

On Wed, Jun 13, 2012 at 12:24 PM, Keith Gardner
...
Loading...