On Monday 15 August 2016 17:41:25 Vlad Stelmahovsky wrote: > I understand need of IO API, but I dont understand why the API should be > implemented using slow and non effective (comparing to C++) JS
Because the IO itself will be slower than the overhead that the engine imposes. In a real world project I did, QDir::entryList was taking 10 seconds to complete (slow embedded device reading USB drive). In a _different_ real world project, QFile::link was taking 20 seconds to complete (desktop app creating a LNK file to add a path to Windows' favorites, and the OS would probably be doing some kind of slow lookup before returning). At this point who cares that QFile doesn't have asynchronous support for a simple read. Even if it had, for a bad roll of the dice you have to face something that is unlikely any framework will provide you (does even exist something non-blocking for readdir?). And if you are triggering something from the interpreter on the UI side, and you need to call into native code to get back to the interpreted one, it's not going to be much different if it's an object you exposed yourself or a library done by a 3rd party. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
