bad performance is a sum of bad design decisions. especially in embedded world. and problem not only with IO speed on embedded, but in memory footprint, GC procedures etc. actually, since you are in Qt forum, you can read recommendations for using JS (as less as possible), you can ask people, why Qt now have Qt Quick Controls 2 and so on
On Mon, Aug 15, 2016 at 10:15 PM, Alejandro Exojo <s...@badopi.org> wrote: > 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 > -- Best regards, Vlad
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
