> Sent: Monday, August 15, 2016 at 4:15 PM > From: "Alejandro Exojo" <s...@badopi.org> > To: interest@qt-project.org > Subject: Re: [Interest] Thoughts on a 'proper' (or standard) file/io API for > QML? > > 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?).
https://nodejs.org/api/fs.html#fs_fs_readdir_path_options_callback (async) https://nodejs.org/api/fs.html#fs_fs_readdirsync_path_options (saync) > 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. Well, that's where the async comes into play, you make the request and and get notified some time later after it completes. Anyway, the important thing is not the performance, it's the fact that you can read and write files with a standard API. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
