[Development] Proposal for "container-oriented deterministic memory manager"

[Konstantin Tokarev]

06.01.2017, 02:06, "Phil Bouchard" <philippeb8 at gmail.com>:
> 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin