Hi Thiago
> Am 12.07.2015 um 19:42 schrieb Thiago Macieira :
>
> On Sunday 12 July 2015 16:57:39 Gunnar Roth wrote:
>> "QMap_insert -- 1 ","WalltimeMilliseconds",0.625,80,128
>
> Please run with -perf -minimumvalue 100. The CPU cycles counter is much
> more accurate and mo
On Monday 13 July 2015 00:45:00 Marc Mutz wrote:
> Since that was written, I have seen QVector create less executable code
> than QList. In theory, QList should expand to less memory, but inefficient
> QLists, what with the heap allocations, probably uses more. Haven't
> investigated much.
Not on
Sune Vuorela schreef op 12-7-2015 om 20:37:
> On 2015-07-12, Andre Somers wrote:
>> become easier to make the transition in user code? Then, if Qt itself
>> changes its API in Qt 6 to use QVector instead of QList, the users' code
>> will just work :-)
> In Qt6, QList can be fixed. The issue is wha
Hi Everybody!
I'm developing a very simple drawing tool for an application:
My target platform is android
The tool is quite simple
A MouseArea over a Canvas.
Every positionChange event on the MouseArea I add the new XY pair to an
array.
In a *workerScript* I make a subdivision of the trajectory to
Hi, everybody
I'm working on a mobile App. The App uses the device camera.
I have set the camera and the videoOutput elements everything works but
the imageProcessing.
I have tested it on android and Linux desktop.
No matter what is set on imageProcessing (saturation, contrast, etc) there
are no
On Monday, July 13, 2015 12:45:00 AM Marc Mutz wrote:
> On Sunday 12 July 2015 22:55:04 Alejandro Exojo wrote:
> > With respect to "less code in your executable", note that in your blog
> > post
> >
> > you said:
> > > On the positive side, QList is a real memory saver when we talk about
> > > the
On Sunday 12 July 2015 22:55:04 Alejandro Exojo wrote:
> With respect to "less code in your executable", note that in your blog
> post
>
> you said:
> > On the positive side, QList is a real memory saver when we talk about the
> > amount of code generated. That is because QList is but a thin wrap
El Sunday 12 July 2015, Thiago Macieira escribió:
> On Sunday 12 July 2015 16:16:07 Smith Martin wrote:
> > I can see by your explanation that QVector is almost always more
> > efficient than QList. But sometimes the difference doesn't matter.
>
> If it doesn't, then why not choose QVector?
I've
El Sunday 12 July 2015, Marc Mutz escribió:
> On Sunday 12 July 2015 13:11:54 Smith Martin wrote:
> > And yet you wrote a blog about it instead of submitting the info to us to
> > update the QList documentation. Currently, the QList page says this:
> >
> > "QList, QLinkedList, and QVector provide
On 2015-07-12, Andre Somers wrote:
> become easier to make the transition in user code? Then, if Qt itself
> changes its API in Qt 6 to use QVector instead of QList, the users' code
> will just work :-)
In Qt6, QList can be fixed. The issue is what to do until then.
/Sune
Hi,
On 12/07/2015 18:56, Smith Martin wrote:
>> If it doesn't, then why not choose QVector?
> My intent in getting the information from Marc is to change the documentation
> of QList to say that.
>
> But QList is easy to use.
Given the API is almost identical, so is QVector. Also having been sho
On 12-7-2015 19:56, Smith Martin wrote:
>> If it doesn't, then why not choose QVector?
> My intent in getting the information from Marc is to change the documentation
> of QList to say that.
>
> But QList is easy to use.
How is it easier to use than QVector?
I will grand you two: QList is two cha
On Sunday 12 July 2015 10:48:10 Thiago Macieira wrote:
> On Sunday 12 July 2015 14:18:04 Lisandro Damián Nicanor Pérez Meyer wrote:
> > While preparing qtbase for a Debian upload on a not-so-clean chroot I've
> > got:
> >
> > QtPlatformSupport: created fwd-include header(s) for
> > /src/platformsu
>If it doesn't, then why not choose QVector?
My intent in getting the information from Marc is to change the documentation
of QList to say that.
But QList is easy to use.
martin
From: development-bounces+martin.smith=theqtcompany@qt-project.org
o
On Sunday 12 July 2015 14:18:04 Lisandro Damián Nicanor Pérez Meyer wrote:
> While preparing qtbase for a Debian upload on a not-so-clean chroot I've
> got:
>
> QtPlatformSupport: created fwd-include header(s) for
> /src/platformsupport/ { bus_interface.h (1), cache_adaptor.h (1),
> deviceeventcon
On Sunday 12 July 2015 14:18:04 Lisandro Damián Nicanor Pérez Meyer wrote:
> While preparing qtbase for a Debian upload on a not-so-clean chroot I've
> got:
>
> QtPlatformSupport: created fwd-include header(s) for
> /src/platformsupport/ { bus_interface.h (1), cache_adaptor.h (1),
> deviceeventcon
On Sunday 12 July 2015 16:29:58 Andreas Aardal Hanssen wrote:
> 2. Analyze (again) when is the time to make Qt’s containers simple wrappers
> over those of stl and/or boost. Performance differences over equivalent
> classes with different APIs should be limited to the API differences
> themselves.
On Sunday 12 July 2015 16:16:07 Smith Martin wrote:
> I can see by your explanation that QVector is almost always more efficient
> than QList. But sometimes the difference doesn't matter.
If it doesn't, then why not choose QVector?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Ar
On Sunday 12 July 2015 16:57:39 Gunnar Roth wrote:
> "QMap_insert -- 1 ","WalltimeMilliseconds",0.625,80,128
Please run with -perf -minimumvalue 100. The CPU cycles counter is much
more accurate and more representative.
You can also try -perfcounter l1d-cache-loads or l1d-
While preparing qtbase for a Debian upload on a not-so-clean chroot I've got:
QtPlatformSupport: created fwd-include header(s) for
/src/platformsupport/ { bus_interface.h (1), cache_adaptor.h (1),
deviceeventcontroller_adaptor.h (1), socket_interface.h (1) }
Which don't get build with the same
Marc, I think you misunderstand the nature of the discussion. I don't think
anyone disputes your analysis of the relative efficiencies of the various
collections. I think you are dismissing the simple elegance of QList for
getting a Qt application up and running quickly. Or, as in my use case, m
On Sunday 12 July 2015 17:34:25 Smith Martin wrote:
> I like QList.
This level of discussion, combined with a complete unwillingness to look
anything up that was linked to in this thread is why I don't try patch the Qt
docs.
And I'm sorry for not having stuck to my initial resolve not to talk
>I expect you to view those videos and to read those articles and then I expect
>you to apologise for this mail of yours.
Well qdoc was taking about 15 minutes to run on Qt5, so I followed Andreas'
advice and changed the high-level algorithm. Now it runs in about 2 minutes.
I suspect that swapp
On Sunday 12 July 2015 16:29:58 Andreas Aardal Hanssen wrote:
> > On 12 Jul 2015, at 16:58, Marc Mutz wrote:
> > That's because your benchmark runs entirely in L1.
> > If you want to test containers of 10, 100, 1000 and 1 elements each,
> > then make
> > - one run over 1×N containers of 1
Hi Milian, hi Marc
> Am 12.07.2015 um 16:06 schrieb Milian Wolff :
>
> On Sunday, July 12, 2015 04:58:01 PM Marc Mutz wrote:
>> On Sunday 12 July 2015 15:05:51 Gunnar Roth wrote:
>>> Hi Marc,
>>>
Better provide a benchmark into which users can easily plug their own
types and that plots
+1
martin
From: development-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Andreas Aardal Hanssen
Sent: Sunday, July 12, 2015 4:29 PM
To:
Subject: Re: [Development] Container benchmark was HEADS UP: Don't use QList,
use Q_DECLARE_
> On 12 Jul 2015, at 16:58, Marc Mutz wrote:
> That's because your benchmark runs entirely in L1.
> If you want to test containers of 10, 100, 1000 and 1 elements each, then
> make
> - one run over 1×N containers of 1 elements each,
> - one run over 10×N containers of 1000 elements each,
On Sunday, July 12, 2015 04:58:01 PM Marc Mutz wrote:
> On Sunday 12 July 2015 15:05:51 Gunnar Roth wrote:
> > Hi Marc,
> >
> > > Better provide a benchmark into which users can easily plug their own
> > > types and that plots relative performance of various containers at
> > > various sizes. Then
On Sunday 12 July 2015 15:05:51 Gunnar Roth wrote:
> Hi Marc,
>
> > Better provide a benchmark into which users can easily plug their own
> > types and that plots relative performance of various containers at
> > various sizes. Then they can use that on their platform, on their type,
> > with thei
Hi Marc,
> Better provide a benchmark into which users can easily plug their own types
> and that plots relative performance of various containers at various sizes.
> Then they can use that on their platform, on their type, with their access
> patterns to determine which container to choose.
>
On Sunday 12 July 2015 13:11:54 Smith Martin wrote:
> >To me it looks like you're trying to argue about a very particular use of
> >QList. At that level of details, it has no business being in the docs.
>
> And yet you wrote a blog about it instead of submitting the info to us to
> update the QLis
Ok, many thanks.
12.07.2015 14:13, Marc Mutz пишет:
> On Sunday 12 July 2015 09:28:31 Denis Shienkov wrote:
>> So, can I add missed QT_DEPRECATED_SINCE (5.2 and 5.5) to the sources
>> for the future 5.5.1 branch?
> For the deprecated_since(5, 5), correct.
>
> For the deprecated_since(5, 2), I'd ta
>To me it looks like you're trying to argue about a very particular use of
>QList. At that level of details, it has no business being in the docs.
And yet you wrote a blog about it instead of submitting the info to us to
update the QList documentation. Currently, the QList page says this:
"QList
On Sunday 12 July 2015 09:28:31 Denis Shienkov wrote:
> So, can I add missed QT_DEPRECATED_SINCE (5.2 and 5.5) to the sources
> for the future 5.5.1 branch?
For the deprecated_since(5, 5), correct.
For the deprecated_since(5, 2), I'd take all branches {5.x| x>=0} which are
still open, and submi
On Sunday 12 July 2015 10:13:30 Smith Martin wrote:
> m trying to get information for updating the documentation for QList.
To me it looks like you're trying to argue about a very particular use of
QList. At that level of details, it has no business being in the docs.
Better provide a benchmark
I'm trying to get information for updating the documentation for QList. At the
moment, it is misleading, judging by what you are saying. Maintaining the
documentation isn't a red herring. It's actually my job.
martin
From: development-bounces+martin.smit
> unless I misunderstood what you're asking for (adding
QT_DEPRECATED_SINCE around a function's definition if it already was
added around its declaration?)
Yes, I mean about:
== foo.h ==
class Foo
{
public:
class Foo();
#if QT_DEPRECATED_SINCE(5,2) // since 5.2
QT_DEPRECATED void
37 matches
Mail list logo
