On 07/23/2017 02:48 PM, Thiago Macieira wrote:
On Sunday, 23 July 2017 11:01:00 PDT Phil Bouchard wrote:
My experience with benchmarking very controlled and deterministic C++ code
(deterministic implies no memory allocation or deallocation) is that the
results vary on a system like that.
I am running it on an Intel Core i7 laptop with an ASUS motherboard and
no I stop processes like the music player before running it.
Did you stop the email client? Did you close the browser? Maybe stopped the
window manager too? You should also disconnect from the network, in case some
packets arrive at the wrong time, disable turbo boost, lock the CPU into
performance mode and disable all but one CPU.
Or 'renice' the process to a higher priority after having killed the
browser at least. I can try later but Linux is pretty good at optimizing
processes that are run multiple times so I don't think it'll make a huge
difference.
That's another example of assigning blame without proof. You may be
completely right and you're very likely partially right. But you need to
stop blaming GC for everything. We don't know how much it's at fault for,
not without evidence.
You can find documentation on this all over the place:
https://www.quora.com/Why-is-the-iPhones-1-GB-RAM-touted-to-be-able-to-compe
te-with-more-than-2-GB-RAM-of-Android-phones/answers/7061202
That's not "documentation". It's not comparing apples to apples: it's
comparing two different applications, written for two different OSes, with two
different frameworks and in two different languages. There's more than just
the GC at work here.
And did you read the link you posted? It's saying that with enough RAM, the
impact of GC is small enough to be ignored.
Yes but when you have more simultaneous apps running then they will
consume more RAM thus the exact same problem will occur.
It's obvious developers aren't perfect either and the more complex the
app is then the more likely there will be a leak. With Root.Ptr it's all
handled implicitly.
Except for the part that developers need to use root.ptr properly. As
you've just written, developers aren't perfect either, so they will make
mistakes. So maybe it's better to have a slightly inferior solution
performance-wise that works in many more cases where the developers are
making mistakes than a perfect solution that requires perfect developers.
Developer won't need to bother about Root.Ptr because I already wrote a
parser to add the necessary node_proxies and metadata.
The developers in question here are not the application writers, but the
framework developers. You're assuming they/you won't make mistakes and that is
not a valid assumption to make.
What matters is what is presented to the client and if they can use
something less error-prone then the faster the apps are going to get
created so it's a win-win situation.
And did I say errors are reported at compile-time? In QML/Javascript
everything is reported at run-time; sometimes in the widget itself,
sometimes on the console and sometimes none is reported and it just
doesn't work!
Are you comparing that to the precompiled QML?
Yes.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
