On Saturday 09 September 2017 10:46:49 Sean Harmer wrote:
> Hi,
>
> I have a use case where we need to create, use and destroy a relatively
> large number of QSharedPointers rapidly. To avoid the malloc overhead it
> would be nice to be able to use a pool of QSharedPointers.
>
> We have QSharedPo
Thanks Allen, bookmarked it :)
On 09/13/2017 03:54 AM, Allan Sandfeld Jensen wrote:
On Mittwoch, 13. September 2017 03:40:03 CEST Ed Leaver wrote:
/What??? /You mean there's actually a /reason/ people aren't knocking
the doors down over these things? =-O
A few months ago I was handed a C++ Cod
On 09/12/2017 09:47 PM, Konstantin Tokarev wrote:
13.09.2017, 04:40, "Ed Leaver" :
What??? You mean there's actually a reason people aren't knocking the doors
down over these things? =-O
A few months ago I was handed a C++ Coding Standard that deigned to prohibit
any further heap allocation
On Mittwoch, 13. September 2017 03:40:03 CEST Ed Leaver wrote:
> /What??? /You mean there's actually a /reason/ people aren't knocking
> the doors down over these things? =-O
>
> A few months ago I was handed a C++ Coding Standard that deigned to
> prohibit any further heap allocation after progra
13.09.2017, 04:40, "Ed Leaver" :
> What??? You mean there's actually a reason people aren't knocking the doors
> down over these things? =-O
>
> A few months ago I was handed a C++ Coding Standard that deigned to prohibit
> any further heap allocation after program initialization. It was origin
/What??? /You mean there's actually a /reason/ people aren't knocking
the doors down over these things? =-O
A few months ago I was handed a C++ Coding Standard that deigned to
prohibit any further heap allocation after program initialization. It
was originally intended for a hard real-time sys
On Monday, 11 September 2017 17:45:01 PDT Ed Leaver wrote:
> Have any of you experience with jemalloc or TCMalloc?
> http://goog-perftools.sourceforge.net/doc/tcmalloc.html
Yes. I don't remember which of the two allocators or the details, but I
remember one of them had a huge thread-safety proble
Don't challenge your allocator, just use intrusive reference counting
(e.g. QSharedData)
12.09.2017, 03:45, "Ed Leaver" :
> Have any of you experience with jemalloc or TCMalloc?
> http://goog-perftools.sourceforge.net/doc/tcmalloc.html
>
> On 09/10/2017 08:26 AM, Thiago Macieira wrote:
>> On Satu
Have any of you experience with jemalloc or TCMalloc?
http://goog-perftools.sourceforge.net/doc/tcmalloc.html
On 09/10/2017 08:26 AM, Thiago Macieira wrote:
On Saturday, 9 September 2017 17:16:24 -03 Sean Harmer wrote:
Yes, vtune shows the line
static_cast(::operator
new(sizeof(ExternalRefCoun
On Saturday, 9 September 2017 17:16:24 -03 Sean Harmer wrote:
> Yes, vtune shows the line
>
> static_cast(::operator
> new(sizeof(ExternalRefCountWithContiguousData)));
>
> is the bottleneck in this particular test case, qt3d/tests/manual/bigscene-
> cpp. I maybe able to reduce the calls to this
Hi Thiago,
On Saturday, 9 September 2017 14:37:00 BST Thiago Macieira wrote:
> On Saturday, 9 September 2017 05:46:49 -03 Sean Harmer wrote:
> > Does anybody have any plans to add such a facility? Or is there some
> > other facility to avoid operator new here for both the QSP and the
> > object it
On Saturday, 9 September 2017 05:46:49 -03 Sean Harmer wrote:
> Does anybody have any plans to add such a facility? Or is there some
> other facility to avoid operator new here for both the QSP and the
> object itself?
There are no plans. We don't have allocators anywhere in Qt, so I doubt this
w
On Saturday, 9 September 2017 11:54:14 BST Giuseppe D'Angelo wrote:
> Il 09/09/2017 10:46, Sean Harmer ha scritto:
> > Does anybody have any plans to add such a facility? Or is there some
> > other facility to avoid operator new here for both the QSP and the
> > object itself?
>
> Just go ahead an
Il 09/09/2017 10:46, Sean Harmer ha scritto:
Does anybody have any plans to add such a facility? Or is there some
other facility to avoid operator new here for both the QSP and the
object itself?
Just go ahead and use std::allocate_shared, or is it in public APIs? Any
such improvement to QShar
Hi,
I have a use case where we need to create, use and destroy a relatively
large number of QSharedPointers rapidly. To avoid the malloc overhead it
would be nice to be able to use a pool of QSharedPointers.
We have QSharedPointer::create() which is analogous to
std::make_shared() that allow
15 matches
Mail list logo
