Why the ember-cli is so slow - ember.js

I migrated my grunt project to ember-cli, I found the time from file modification to liveload completion was so long, about 10 minutes.
After I installed ember-cli-windows, ember-cli-windows-addon, no obvious prompt was gained. The following is one example output after ember-cli-windows, ember-cli-windows-addon installed:
file changed routes\services.js
Build successful - 382781ms.
Slowest Trees | Total
----------------------------------------------+---------------------
Babel | 82175ms
Concat: Vendor | 75980ms
Funnel: App JS Files | 57393ms
JSHint app- QUnit | 49491ms
ES6: App Tree | 41827ms
Slowest Trees (cumulative) | Total (avg)
----------------------------------------------+---------------------
Babel (2) | 82394ms (41197 ms)
Concat: Vendor (1) | 75980ms
Funnel: App JS Files (1) | 57393ms
JSHint app- QUnit (1) | 49491ms
ES6: App Tree (1) | 41827ms
By contrast, the build process can be finished in 2~3 seconds in grunt project after file modification.
I use windows 7.

You ask
Why the ember-cli is so slow
It is not ember-cli per se that is slow, it is Broccoli. Reasons include:
Broccoli copies files instead of symlinking under Windows. To avoid this, run your builds in a command prompt with administrator privileges.
Broccoli is disk-intensive. To solve this, get an SSD.
Broccoli is processor intensive. To solve this, get a faster machine (preferably non-Windows).
Broccoli creates huge numbers of temporary files in tmp, which can slow down performance. To solve this, clean out tmp from time to time.
Broccoli is known to be inherently slow. You can find relevant questions on the broccoli site. To solve this, wait for the broccoli people to address performance issues, which is on their roadmap. Substantial improvements have already been made, so upgrade to the latest version of everything.
Broccoli rebuilds everything over and over again, including things which did not change. To solve this, manually tweak your build process to exclude certain things and do them manually as-needed. For instance, let's say you are bringing in a 200KB external JS package via bower, and app.import'ing it in your Brocfile.js. As a temporary work-around, and to see if it makes a difference, remove that file from the Broccoli world and load it directly in index.html. The same applies to large CSS files.
Broccoli will run babel in a default installation. Babel is not that slow, but it does take time. To solve this, if you are not using ES6 syntax, remove the babel dependency.
Your virus scanner may be trying to scan the thousands of files Broccoli creates. ember-cli-windows deals with this problem only for Defender. If you are using a different anti-virus package, to solve this add your dev directory to its list of places to skip.
For your reference, I have a small Ember project I build in an Ubuntu Virtual Box VM with Windows host on a fast machine with SSD, and builds take 2-3 seconds.
You may also want to consider asking this on an ember-cli list. You could also choose a different framework that does not bake in an immature and inefficient build system.

For windows users, one will need to correctly enable symlinks. As our friends at Microsoft are actually active users of both ember and ember-cli. They have provided an addon that does exactly that.
See: http://ember-cli.com/user-guide/#windows for further details.
For all users see: https://github.com/ember-cli/ember-cli/blob/master/docs/perf-guide.md
[Update]
In the last 6 months several large performance improvements have landed, some are seeing one or two orders of magnitude improvements (obviously this depends on some factors...)
As time permits, more performance improvements are planned, one particular important one is decoupling the need to rely on symlinks or copying. Which should make our windows counterparts (and those with slower drives) quite happy.
For anyone currently feeling like they are seeing less then optimal performance, let me recommend this guide: https://github.com/ember-cli/ember-cli/blob/master/docs/perf-guide.md
Many of the recent improvements have been done in a backwards compatible way, but do require dependencies being upgraded, be sure to upgrade relevant depends, and use that guide to track down any remaining issues and report them.
Windows Subsystem Linux also appears to now work very well!

The best solution for fixing performance issues in windows is running a Ubuntu (or whatever linux you want) in a virtual machine, and running ember serve inside it, using NFS to share folders with host.
I had the exact same problem and I'm getting now sub-second building times. Tried all the solutions found here and in the internet, but without luck. I got 10x performance when I migrated to a Ubuntu VM.

Related

Visual Studio compiler (VBCSCompiler.exe) freezes and pegs CPU for forty-five seconds before getting to work

Environment
I'm using Visual Studio 2019 version 16.7.2 on a Windows 10 VM, hosted by Parallels on a brand new MacBook Pro. The VM has eight virtual processors and sixteen gigs of RAM.
Nothing other than Visual Studio is installed on the VM.
What I'm trying to do
I'm trying to compile a Visual Studio solution consisting of seventeen projects. The projects are relatively small. They're all C# console applications or DLL libraries targeting .NET Core 3.1.
Problem
Typically a Rebuild Solution executed after a Clean Solution takes place in about ten seconds. A typical Build Solution (Ctl-Shft-B) that I execute throughout the day takes place almost instantaneously.
But occasionally, in maybe one build out of five, building the solution/projects causes VBCSCompiler.exe to consume 99% CPU usage and freeze up for approximately thirty to forty-five seconds prior to executing the build. Once it starts executing the build though, everything completes normally. This long delay which occurs time and time again is making my development cycle terribly frustrating. I'd like to find a way to eliminate this delay.
What's Changed
The build executed fine on my Amazon Web Server Windows 2016 m4.xlarge VM. I recently switched over to the Parallels VM to save money. That's when the problem began.
Again, I want to reiterate that the Parallels VM is clean. Nothing other than Visual Studio is installed there.
What I've Tried
The following tactics were applied to no avail.
(1) I turned off the Defender real-time virus checker.
(2) Based on the information in this post, I went to Tools | Options | Nuget Package Manager | General, and unchecked 'Allow Nuget to download missing packages' and 'Automatically check for missing packages'
(3) In Tools | Options | Projects and Solutions | Build and Run, I set the maximum number of parallel projects builds to one.
(4) Based on an answer to an unrelated question, I learned that I can view more information about the build process by setting 'MS Build project build output verbosity' to Detailed. I did so. I waited for the freeze to occur so I could examine the last line of output prior to the freeze. It reads as follows:
Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn
This line always appears immediately before a freeze.
(5) Based on the output above, I Googled 'shared compilation' and discovered this post.
As a hobbyist programmer, the discussion that took place there, as well as the link in the accepted answer is well above my pay grade. It's unintelligible to me. If the answer lives in that post, I can't decipher it.
Any ideas on how to solve this intermittent freeze? If I can't figure it out, I'll have to assume it's something about my Parallels Windows 10 VM that's causing the problem, and revert back to developing on an Amazon server. I'd prefer to avoid that if possible because of the added expense.
Thanks for your consideration.
Best,
Festus

Minimize and Uglify not working in Ionic2

I'm trying this, I set up alwaysRun to true in cordova-uglify and ionic-minify folders, but the only way to see the files minimized and uglified is running ionic build android --release (but i don't want to generate the app for PRD yet)
If I do
ionic build android --minimize
The result is the full file, not minimized.
Any idea how to get the files minimized? I'm trying to fix a performance issue with this as the app takes 12 seconds to open and in all sites suggest this as a performance improvement.

SVN and SFTP synchronisation with eclipse

I have to create and configure an eclipse (Mars 2) for a C project. The project is on a SVN repository, and can only be compiled on a specific linux redhat server that has the appropriate toolchain.
What I need is an IDE that would allow me to commit my changes to the repository and that would automagically synchronize them on the Linux server. I tried a few things but none of them worked. I must (to my great regret) avoid the need of a terminal while using that IDE, but of course not while configuring it.
Firstly, I used the Remote System Explorer feature in eclipse. I connected succefully to the server, created a "Remote Project" that I could open in the C/C++ perspective. However, the whole thing is impossible to use, as it has no indexation, I had to create "User Actions" in order to compile (which is on my point of vue pretty anti-ergonomic) and the SVN plugin does not detect the project as an SVN copy. Furthermore, in the C/C++ perspective, there is a 2s gap between the moment I type something, and the moment it appears on my screen.
I also tryed to mount a network filesystem on my local machine, with sshfs, and if it works far better, I still experience lags. Also, I had to write a Makefile and call my compiler via "ssh $(USER)#$(HOST) build.ksh". (one of the point of the projetc is to write a real Makefile...). But SVN is working.
I also tried to run eclipse on the host machine, with X forwarding, and if it works perfectly, there is still lags...
Finally, I tried an sftp synchronisation, but it seems I can't use my SVN plugin features and the sftp together.
I am out of solutions, and pretty frustrated as I feel that this kind of things should be pretty easy. I mean, all I want is that eclipse automatically copy my files on my remote home directory... Thanks for your help...
To me this sounds like a perfect use-case for a continuus integration (CI) system. Generally speaking, this CI system pulls the code from your repository (for example in regular intervals) and then executes the build chain, collects artifacts, informs you about the state of your build, etc.
Although it originated from the Java world, I have successfully used Jenkins for continuus integration of C-projects on a Linux server, but there are others, like TeamCity or GitLab CI (the latter would require you to switch to Git, but it's a really neat system with a YAML configuration for CI).
Of course CI systems have a learning curve - you don't something like a free meal - but it may really be worth the effort.

How to build WSO2 4.X from source?

We have been trying to build wso2 (various products) from source to no avail.
I have looked for information all over (with assistance from Google) and followed the few instructions we have found but without luck.
I have, on the other hand, found various posts discussing this process and how error prone it is due to this or that.
Don't get me wrong, WSO2 looks like an amazing framework to work within but confidence in the project is not boosted by the complicated/error prone/enormous build process.
Does anyone here have a good description/recipes to build the 4.x.x version of carbon?
I really don't think it is intentionally hard to build. The product is huge with tons on developers working on it. Most of the issues seem to be around erroneous commits by developers. My understanding is that WSO2 will be changing the development process to make it more robust (source: Manoj's Comment).
The WSO2 set of products are awesome and well engineered. They can be built, but you will need to persist and resolve issues along the way.
It took me quite a few days to get a working build in my spare time. Here is a rough sequence of tasks to perform:
1) Checkout the 4.0.0 branch:
svn co https://svn.wso2.org/repos/wso2/carbon/orbit/branches/4.0.0
svn co https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.0.0
svn co https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.0.0
For more information of the code base high level structure, see here: what is wso2 'orbit', 'kernel' and 'platform'?
2) Decide which version of a product you need to build - Which version of patch-release to build?
3) Build the three separate code bases (build the main branch plus patch-release versions below your required version).
build orbit 4.0.0/ Then build orbit/patch-release/4.0.x
build kernel 4.0.0/ Then build kernel/patch-release/4.0.x
build platform 4.0.0/ Then build platform/patch-release/4.0.x
Note to build:
use Java 6 (Use Sun/Oracle JDK - not OpenJDK)
use Maven 3
set MAVEN_OPTS to -Xms512m -Xmx1024m -XX:MaxPermSize=1024m
you will probably need to use the following mvn command line: mvn clean install -Dmaven.test.skip=true
You will find the built distribution zip file here: ROOT/distribution/product/modules/distribution/target/ (source: WSO2 Carbon 4.1.x - how to make the distribution)
Be prepared to put in the time to hunt down and fixing issues as you encounter them. Most issues seem to be due to maven dependency issues. Using google, you can usually find the answer. Also you post any issues you need help with on stackoverflow.

Local continuous integration system for C++?

"local continuous integration system" may not be the correct term, but what I'm hoping to find is an continuous integration system that can be configured to monitor changes to local files (C++ files in particular) and 1) try to compile the affected object files (stopping on first failure), and if successful and no new source file changes 2) link the affected binaries, and if successful and no new source file changes 3) run affected tests.
By monitor changes to local files, I do not mean monitor commits to a revision control system, but the state of local files as they are saved. Ideally the system would be provide integrations into source editors so it could monitor changes in the editor that haven't even been saved to disk yet.
Ideally it would also provide a graphical indication (preferably on Windows 7) of current and recent status that quickly allows drilling into failures when desired.
The closest thing I found was nose as described here but that only covers running Python tests not building C++ files.
The closest thing to what you are looking for is cdash and the Boost test bench; I think that a tool like the one you are looking for will never exist for C++ because compiling each project after editing a single file it's only a waste of time in a productive C++ workflow.
Continues Integration is a rising concept today, so you are not alone here.
Assuming you are developing on Windows, if you are working with Microsoft Visual Studio
you may consider Microsoft's Visual Studio Team Foundation Server (TFS)
(formerly Visual Studio Team System).
That will give you Source-Control AND Build-Automation in one package,
with great integration to Microsoft products, of course
(I think there is a free version for MSDN users).
If not keen on Microsoft products, or just looking for build-automation,
I would recommend a great Open-Source Continues Integration tool:
Jenkins CI.
Good luck!
I would look at Jenkins CI - it is a good tool, works on any platform, and can be configured to do almost anything. I used it to run Python Code that talked to a mobile phone, made calls and recorded those calls (and tested the "quality" of the call, although my project never got the £xxxx real quality software, as we were just showing a concept), and then Jenkins would produce graphs of "how well it worked".
You can also do what you describe of "chaining" - so it would discover that your source has changed, try to build it [generally this is done using make, so it would automatically stop at the first errored file (although it could be hundreds of errors in one file!)]. Compile and build success then chains to running tests. Not entirely sure how you determine what is "relevant". If your test cycle isn't enormous, I'd run them all!