There’s a new release that went out just before the translation mod that does
the shared cache - although the source-output directory is currently very
similar to build-output, this is only temporary because build options can
change the code which is output.
This is primarily that calls to qx.core.Environment.get and .select are
optimised out where QxCompiler or generate.py can know the outcome; for
example, in build target where the qx.debug is set to false, QxCompiler can
remove this code completely:
if (qx.core.Environment.get("qx.debug")) {
// ... snip ...
}
I think that this is a major difference in size between ./generate.py build
target and the QxCompiler, because QxCompiler currently does not do the
elimination.
NOTE: I have renamed qxcompiler.makers.SimpleApp to qxcompiler.makers.AppMaker
to follow other naming conventions.
So in the changes I pushed earlier this evening, the AppMaker now supports
making multiple Applications simultaneously – you can see an example in
./test/compile-app-demo.js and ./test/compile-app-demo-build.js:
maker.addApplication(new qxcompiler.Application("qxt.Application").set({
theme: "qxt.theme.Theme",
name: "appone",
environment: {
"qxt.applicationName": "App One"
}
}));
maker.addApplication(new qxcompiler.Application("qxt.Application").set({
theme: "qx.theme.Simple",
name: "apptwo",
environment: {
"qxt.applicationName": "App Two"
}
}));
For every Application you want to compile, just add a new instance of
qxcompiler.Application; the first parameter to the constructor is the main
class name for the application. You specify the theme as a property, and note
the new “name” property – previously, one application related to an
“index.html” file that loaded files from the “script” folder, whereas in this
new release the name property is used to name both the .html file and the
script folder, so each application needs a unique name.
In the example above, the two applications differ just in theme but because
they share the same output directory, the overhead of second application adds
around 400ms on my laptop when compared to just the one application.
This might not be exactly what you were expecting when compared to generate.py
because entire applications can be sent out into different directory trees? If
it’s necessary to have separate dircetory trees per application, then either
the transpiled code would need to be copied to each destination tree or there
would need to be a URI for transpiled code and another for the application.
Anyway, see how you get on :)
Cheers
John
On 21/02/2016, 19:23, "Dimitri" <mi...@cargosoft.ru> wrote:
John, Fritz,
Yes exactly - I was talking about profiling QxCompiler itself. At that
moment I was experimenting with shared database and was wondering why
it doesn't bring any speedup. I thought profiling would help to
understand where QxCompiler spends most time; later it turned to be
more fundamental issue.
I've experimented with a bit with incremental builds in our CI. So far,
I think incremental builds are fine for CI builds (triggered by
commits). That build directory isn't cleared each time didn't cause any
complications yet. It's not a problem that first build takes
significant time, it's only time of subsequent builds that matters.
It's also a good practice to perform clean builds for releases, but
slow release builds are quite acceptable since they don't occur
frequently.
However, I don't think efficient shared cache is impossible "by
design". I've looked into {qxt,myproject}/{source,build}-
output/transpiled/qx/*, did a byte-by-byte comparison and found that
*.js files are identical (therefore, they could probably be cached
across targets and libraries). Of course, there was difference in which
files were present, due to different dependencies.
(Besides, all the *.map files contain "null", are they really needed?)
Speaking of dependencies, I did some comparison between qxt and our
project:
Framework classes used: 283 vs. 378
Contribs: UploadMgr (both)
Uncompressed script: 4.8M vs. 6.4M
Compressed script (QxCompiler): 1.4M vs. 1.9M
Compressed script (generate.py): 700K vs. 1M
Definitely there is some room for optimization :)
John, sorry for delay in conversation. I'll be answering you on server-
side JS soon.
Dimitri
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
