06.01.2017, 02:06, "Phil Bouchard" <[email protected]>: > On 01/05/2017 03:09 PM, André Pönitz wrote: >> On Thu, Jan 05, 2017 at 07:57:54AM -0600, Thiago Macieira wrote: >>> Em quinta-feira, 5 de janeiro de 2017, às 07:26:52 CST, Phil Bouchard >>> escreveu: >>>>> AFAIU QtQuickCompiler has nothing to do with memory management, its main >>>>> purpose is reduction of start up time and obfuscation of sources. >>>> >>>> Ok I assumed that execution time would be affected because the code is >>>> compiled. >>> >>> The code is compiled anyway. The difference is only *when* it is compiled: >>> at >>> release time of your application or when your user launches it (JIT). >> >> It's not the only difference. A JIT compiler has typically not the same >> scope/abilities/optimization opportunities as a real compiler, not to >> mention >> deficiencies in a language that has 'double' as only numeric type. >> >> So "compiler" and "compiler" are apples and oranges in this case. > > Right, g++ is much more portable than JIT. > >>> JIT = Just Too Late (because it will start compiling the moment you need >>> it) >> >> Correct. >> >> And done on each and every (often under-powered) device out there, if not >> even >> done on each and every application start, instand once when preparing binary >> packages. > > In Brave New World we would have the QtQuickCompiler running on the fly, > followed by g++ and the browser could "dlopen" the generated library. I > don't see any better solution than this.
This does not make any sense, as QtQuickCompiler does exactly the same thing at compile time as regular Qml/JS parser does at run time > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
