On 07/23/2017 12:53 PM, Thiago Macieira wrote:
On Sunday, 23 July 2017 07:48:48 PDT Phil Bouchard wrote:
* You still did not provide evidence that the problems in your QML
application where due to the garbage collection.
All you have to do is create a ListView with images in the ListView
Items, scroll the ListView and then you will see the ListView's
scrolling speed not being uniform in an unpredictable way. Whatever's
unpredictable is caused by the GC.
Are you running this on a multitasking system with other processes and threads
running? Maybe on a CPU and GPU that can increase and decrease the clock
speed? Maybe even a CPU that has thermal-limited turbo-boost that periodically
overclocks the CPU?
If you are, then I think you should consider other sources of
unpredictability.
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.
It's like Google's choice of using Java for the Android just because
it's popular. But the Android hangs constantly because of the GC that
runs in the background.
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-compete-with-more-than-2-GB-RAM-of-Android-phones/answers/7061202
"ARC differs from garbage collection in that there is no background
process that deallocates the objects asynchronously at runtime. Unlike
garbage collection, ARC does not handle reference cycles automatically.
This means that as long as there are "strong" references to an object,
it will not be deallocated. Strong cross-references can accordingly
create deadlocks and memory leaks. It is up to the developer to break
cycles by using weak references."
https://en.wikipedia.org/wiki/Automatic_Reference_Counting
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.
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!
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
