How to speed up edit-compile-test cycle in AOSP? - android-source

I followed https://source.android.com/setup/start. It mostly worked, except that I needed to modify acloud to work on my Arch Linux system and pass it --launch-args='-vm_manager=qemu_cli' because the default VM manager of Cuttlefish (crosvm) crashes on my system.
I make changes inside frameworks/opt/vcard. Running atest AndroidVCardTests inside that directory takes 3:17 if a file was changed since the last run and 1:53 if no file was changed. This makes edit-compile-test cycles very slow. Is there a way to speed this up?
When running the command while no emulator is running, it aborts after 0:47. It seems like most of the time is spent installing the tests on the device. The tests itself seem to be fast (it reports a few ms of time for each test).
Because it’s slow even if no file was changed, I think that most the rest of the time is spent finding out which files need to be recompiled. However, I know that I only changed files inside frameworks/opt/vcard.

Related

Unable to start VSCode; suggestions for debugging?

I'm working on a disconnected network, so some options are a bit limited. Also, we have SAs who handle stuff like system updates (so, for instance, it is possible that there was a system update in there that I know nothing about).
However, I had 1.33.1, then 1.34.0, then 1.38 versions of VSCode working on my (Windows 10) machine. One day, for no apparent reason (I hadn't just installed something, for instance), 1.38 stopped working. It wouldn't even start up. Running 'Code --verbose' from the command line produced no output (the mouse cursor turned briefly to a spinner, but nothing even showed up in Task Manager, let alone something like a splash screen).
I did get an error message in the Application log, which included the lines (more or less; remember, no cut-n-paste possible):
Faulting Application Code.exe, version: 1.38.0
Faulting module ntdll.dll, version 10.0.16299.936
Exception code: 0xc0000374
Faulting Application path: c:\Program Files\Microsoft VS Code\Code.exe
Faulting module path: c:\Windows\System32\ntdll.dll
Re-installing VS Code (with or without system restart after uninstall) did nothing.
Removing all extensions (we have a bunch) did nothing
Installing 1.39.2 did nothing
The only good thing is that I can still run 1.34.0, if I reinstall that (did not try 1.33.1, and I don't have any in-between versions from 1.34 to 1.38 to try). So at least I'm not completely shut out.
I also tried deleting basically all of workspaceStorage, to no effect. Nor did renaming my storage.json.
The biggest weirdness, to me, is that the path to ntdll.dll is in System32, rather than in SysWOW64 (is there some way to force usage of the latter?). Second, why did 1.38.0 work just fine for a while, and then stop.
So, I'm curious if anyone else has seen this problem, and/or if anyone has any idea what else could be done to get more insight into what's causing this.
(edit: I plan to file bug for VSCode, but been waiting on confirmation email to finish creating my github acct for some time now. sigh)
I've had exactly the same problem twice. I'd been running the application since June 2019 and then in March of this year, Yep! Exact same problem as you encountered. A simple reinstall fixed that, but I've had the same problem again today and after some investigation, Windows 10 was telling me that I didn't have the right permissions to access the item (this is using the Owner's account!). Attempting to reinstall failed, with errors stating that the file / directory all ready existed and couldn't be overwritten or renamed. Attempting to un-install the application was only partially successful with the executable code.exe still remaining afterwards. The only way I managed fix it this time was to reinstall to a directory with a different name. Surprisingly though, all the existing workspaces, projects and extensions even were intact and the application opened where I had left off as though nothing had happened. This is a little worrying I have to say! But that's how I fixed it this time.

first call to msbuild hangs

I am using a powershell script that internally calls msbuild to build my solutions. This works in principle, so the solution files are ok.
I can repeat the build, it works flawlessly.
But the build hangs
the first time I start the script (after reboot)
after some time / actions during the work day, no idea what changes
So my suspicion is, that msbuild is using some component that is not loaded when I reboot / that is unloaded during the work.
But I have no clue how to find the problem...
I am using this exe:
C:\Program Files (x86)\MSBuild\14.0\bin\MsBuild.exe
Any ideas?
For anybody running into this issue: Roslyn does a "shared compilation" by default, which means that results of compiles are used for further compilations to gain speed. You can switch this of by providing "False" for UseSharedCompilation in VBPROJ files or using a similar switch for MsBuild. Switching this off will do slower compiles but the run does not hang.

Running a GWT project takes a lot of space

I have been observing this for a few days now, every time i run a GWT project on my web page a lot of space on my local C drive is taken, which is about 200 MB per run. A few days ago the space left on the drive was about 50 GB, now only 4 GB is left. How do i free the space on my C drive without removing the projects i made?
GWT generates a lot of temporary files, some of them relatively big, but cleans up after itself.
That's unless you run DevMode from within Eclipse, in which case it'll kill DevMode so abruptly that it cannot do the cleaning. This is a known issue of the Google Plugin for Eclipse: https://code.google.com/p/google-plugin-for-eclipse/issues/detail?id=74
You'll find various workaround in the issue originally reported against GWT: https://code.google.com/p/google-web-toolkit/issues/detail?id=5261
Files are all in the temporary folder anyway, which you should clean regularly anyway (for example, setup a scheduled task to do it when you start or shutdown your computer, as is done on most other OSes)

git Repository: Is Previous File Version Accessible Outside of Xcode

With a git repository setup for my iPhone app, is there a way to gain access to the last committed version of a file outside of XCode? Can I find the previous version somewhere on the hard drive, or perhaps piece the file together somehow? The current version of the file is now corrupt (see story below for how this happened if interested), and I'd very much like to retrieve the changes I made since the last time I was able to backup the files outside of git. I don't have the ability to access anything in XCode or run anything on the Mac outside of what's available through Max OS X Installer, so I'd like to access the previous version of the file if that is possible.
Story that pisses me off begins here:
On a recent 6 hour flight, I took my MAC with me on the plane, committing changes to the git about 2 times during this period. Everything functioned fine on the MAC all the way until we had to shut down all electronics at the end of the flight. At that time, I told the MAC to shutdown, but it froze instead. Wanting to avoid an airline incident, I forced the computer to shutdown by holding the power button after waiting for over a minute.
When I turned on the computer later that night, it would no longer boot, instead freezing on the Apple logo and the spinning gear. I used my install disk to bypass logging in and accessed Disk Utility, which proceeded to FAIL repairing my drive. The hard drive still mounts, so I'm able to get into my files. I accessed the absolutely essential file needed for my app, and when I opened it on my Windows machine it contained garbage. Of course most of the other files were all fine :-/
Story that pisses me off ends here.
So, I'm still trying to fix my stupid MAC, but before proceeding and possibly needing to wipe the drive, I'm trying to grab all the files I can, so any help is definitely appreciated.
To wipe out the current changes and see the most recent committed version,
git checkout HEAD .
To wipe out the current changes and see the previous committed version,
git checkout HEAD^ .

Will running everything from RAM disk speed up scala compile time?

Scenario:
The machine I use for development have 32Gb of DDR3 RAM, i7 3770, SSD. The project is large, Scala compiles fast most of the time during incremental compilation but sometimes a single change leads to recompilation of hundreds of files, it then take some time to compile all and some good time for jrebel to reload all changed files.
Question:
Will putting everything on a RAMFS (Mac) make compile and jrebel reload significantly faster?
My plan was to put everything directly related to the project in a RAMFS partition ( .ivy, project source, .sbt, maybe even copy JDK. etc). I would create a script to do all that in the boot or manually, that won't be a problem. Also, I would setup file sync tasks, so, losing a change won't be a concern in case of a OS failure.
Updates:
log says around 400 among java and scala sources are compiled after a clean.
after changing a file in a core module, it recompiles 130 files in 50s.
jrebel takes 72s to reload after #1 and 50s after #2
adding -Drebel.check_class_hash=true made jrebel reload instantaneous after #2.
I am quite happy with these results, but still interested on how to make scala compilation even faster, since cpu usage gets at most 70% for just about 5 seconds in compilation process that takes 170s, overall cpu usage during the compilation is 20%.
UPDATE:
After putting JVM, source, .ivy2 and .sbt folders on RAMDISK, I noticed a small improvement on compile time only: from 132s to 122s ( after a clean). So, not worth the trouble.
NOTE:
That is excluding the dependency resolution, since I using this approach to avoid losing dependency resolution after a clean.
I have no idea what speedup you can expect with a Mac, but I have seen speedups on Linux compiling the Scala compiler itself that are encouraging enough to try. My report (warning : quite Linux-specific) is there.
You can try setting a VM argument -Drebel.check_class_hash=true which will check the checksum before reloading the classes.
There's often very little point in a RAM disk if you're working on Linux or OSX. Those OS's cache the files anyway.
https://unix.stackexchange.com/a/66402/141286