cc_library for Android builds very slow on WSL

[sigmaxipi]

Description of the problem / feature request:

On Windows Subsystem for Linux, building a cc_library for Android takes 15+ seconds. Building the same code without targeting Android takes under a second. I've only been able to repro this issue on WSL.

Feature requests: what underlying problem are you trying to solve with this feature?

Build native Android apps on WSL.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

My minimal repo:

> cat BUILD WORKSPACE jni.cpp
# Minimal BUILD
cc_library(name = "libtest", srcs = ["jni.cpp"])

# Minimal WORKSPACE
android_ndk_repository(name = "androidndk", path = "/home/sxp/android/ndk-r19c")

// Minimal cpp file
int foo() {return 1;}

Change the return 1; to a different number to have incremental builds. A basic time bazelisk build :libtest takes 1-2 seconds. But if I create an Android build via time bazelisk build :libtest --crosstool_top=@androidndk//:default_crosstool --cpu=x86 --profile=prof or use an android_binary, I get:

INFO: Build options --cpu, --crosstool_top, and --host_crosstool_top have changed, discarding analysis cache.
INFO: Analyzed target //:libtest (1 packages loaded, 6124 targets configured).
INFO: Found 1 target...
Target //:libtest up-to-date:
  bazel-bin/liblibtest.a
  bazel-bin/liblibtest.so
INFO: Elapsed time: 18.455s, Critical Path: 17.09s
INFO: 4 processes: 1 internal, 3 processwrapper-sandbox.
INFO: Build completed successfully, 4 total actions

real    0m19.121s
user    0m0.094s
sys     0m0.109s

Also, if I run ...build -s... to get the actual Android commands and then manually run those, the commands complete instantly.

What operating system are you running Bazel on?

Microsoft Windows [Version 10.0.19041.685] and Ubuntu 18.04 bionic [Ubuntu on Windows 10]

What's the output of bazel info release?

release 3.7.2

Have you found anything relevant by searching the web?

Maybe #7527 is related based on the profile info below?

Any other information, logs, or outputs that you want to share?

I've attached a profile. Remove the file extension to view in chrome://tracing. The two big chunks are sandbox.CreateFileSystem and sandbox.delete.
prof_NOT_A_ZIP.zip

[sigmaxipi]

If I use --spawn_strategy=local, the problem goes away.

#4619 might also be related.

[chancila]

likely a filesystem performance issue, WSL still goes through NTFS under the hood right?

I haven't done much building on windows but macos also has this issue compared to linux although it doesn't sound nearly as bad, the reason you're not seeing the normal/host build have any perf degradation is because the autoconfigured cc_toolchain isn't fully sandboxed, the ndk toolchain is, and creates a lot of symlinks on the filesystem per sandbox invocation.

[sigmaxipi]

@chancila , you're right. I thought the WSL filesystem was going to use a disk image similar to what VmWare does. But it looks like it's a normal NTFS system under %LOCALAPPDATA%\Packages\DISTRIBUTION_NAME\LocalState\rootfs\UNIX_PATH\....

I guess I'll stick with the non-sandboxed version for now.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!