Excessive loading time for local repo

[Onath Claridge]

For compatibility with sandboxing, I need to create a local repository to include .so files from /usr/lib/x86_64-linux-gnu. However, creating a new_local_repository with this as its path leads to an incredibly long loading phase.

For example, right now that repo's build file has a single filegroup with a single file:

    filegroup(

        name = "gtk",

        srcs = ["libgtk-x11-2.0.so"],

        visibility = ["//visibility:public"],

    ) 

Building that filegroup from the command line takes about 2.5 minutes. We have lots of local repositories that work just fine - this issue is particular to /usr/lib/x86_64-linux-gnu.

Are there any workarounds? E.g. can I suggest to Bazel that it ignore contents of this directory that It might be spending a little too long inspecting?

[Janak Ramakrishnan]

bazel doesn't examine files in a directory like that unless there's a glob in the BUILD file is similar. Can you run with profiling enabled, and maybe also hit ctrl-backslash during the loading phase to see what's going on? You can run with --nobuild --noanalyze to avoid doing the whole build.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/8d33a2ad-2b0e-4f22-b506-bbe2cd32c095%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Onath Claridge]

How do I run with profiling enabled?

Each time I hit ctrl+backslash, I get this message:

Sending SIGQUIT to JVM process 73717 (see /home/claridge/.cache/bazel/_bazel_claridge/55dc5e1f68c8d183e88ba3315f76c03b/server/jvm.out).

I've attached the trace from jvm.out.

[Kristina Chodorow]

bazel build --profile=myprofile.out --nobuild --noanalyze //your:target

Then send the myprofile.out file (or you can look at it yourself by running 'bazel analyze-profile --html myprofile.out'). I wrote a post on it a little while ago, if you want more details: http://www.kchodorow.com/blog/2015/09/18/build-y-u-go-slow/.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/b9ab9856-3dc4-42fa-a14f-e41192875c78%40googlegroups.com.

[Onath Claridge]

Thanks! My profile.out is attached. Bazel spent nearly the entire time in the "Load packages" stage.

[Janak Ramakrishnan]

Looks pretty clear from your stack trace what's going on. I was wrong:
when creating a repository, we seem to individually symlink every
file: https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/repository/RepositoryFunction.java#L337

Sample stack trace:
"skyframe-evaluator 142" #722 prio=5 os_prio=0 tid=0x00007f1c5c22f000
nid=0x1265a runnable [0x00007f1c333e5000]
java.lang.Thread.State: RUNNABLE
at (C/C++) __pthread_cond_wait( (/usr/grte/v4/lib64/libpthread.so.0))
at (C/C++) Monitor::ILock(Thread*)(
(/usr/local/buildtools/java/jdk8-google-v7-64/jre/lib/amd64/server/libjvm.so))
at (C/C++) Monitor::lock_without_safepoint_check()(
(/usr/local/buildtools/java/jdk8-google-v7-64/jre/lib/amd64/server/libjvm.so))
at (C/C++) SafepointSynchronize::block(JavaThread*)(
(/usr/local/buildtools/java/jdk8-google-v7-64/jre/lib/amd64/server/libjvm.so))
at (C/C++) JavaThread::check_safepoint_and_suspend_for_native_trans(JavaThread*)(
(/usr/local/buildtools/java/jdk8-google-v7-64/jre/lib/amd64/server/libjvm.so))
at (C/C++) ThreadStateTransition::transition_from_native(JavaThread*,
JavaThreadState) [clone .constprop.96](
(/usr/local/buildtools/java/jdk8-google-v7-64/jre/lib/amd64/server/libjvm.so))
at (C/C++) jni_GetStringLength(
(/usr/local/buildtools/java/jdk8-google-v7-64/jre/lib/amd64/server/libjvm.so))
at (C/C++) JNIEnv_::GetStringLength(_jstring*)(
(/home/claridge/.cache/bazel/_bazel_claridge/install/a195658d9801c77a5fa56b06ff9698a7/_embedded_binaries/libunix.so))
at (C/C++) GetStringLatin1Chars(JNIEnv_*, _jstring*)(
(/home/claridge/.cache/bazel/_bazel_claridge/install/a195658d9801c77a5fa56b06ff9698a7/_embedded_binaries/libunix.so))
at (C/C++) link_common(JNIEnv_*, _jstring*, _jstring*, int (*)(char
const*, char const*))(
(/home/claridge/.cache/bazel/_bazel_claridge/install/a195658d9801c77a5fa56b06ff9698a7/_embedded_binaries/libunix.so))
at (C/C++) Java_com_google_devtools_build_lib_unix_FilesystemUtils_symlink(
(/home/claridge/.cache/bazel/_bazel_claridge/install/a195658d9801c77a5fa56b06ff9698a7/_embedded_binaries/libunix.so))
at com.google.devtools.build.lib.unix.FilesystemUtils.symlink(Native Method)
at com.google.devtools.build.lib.vfs.UnixFileSystem.createSymbolicLink(UnixFileSystem.java:315)
- locked <0x00000000989f7480> (a com.google.devtools.build.lib.vfs.Path)
at com.google.devtools.build.lib.vfs.Path.createSymbolicLink(Path.java:778)
at com.google.devtools.build.lib.vfs.FileSystemUtils.ensureSymbolicLink(FileSystemUtils.java:417)
at com.google.devtools.build.lib.vfs.FileSystemUtils.ensureSymbolicLink(FileSystemUtils.java:368)
at com.google.devtools.build.lib.rules.repository.RepositoryFunction.createSymbolicLink(RepositoryFunction.java:351)
at com.google.devtools.build.lib.rules.repository.RepositoryFunction.symlinkLocalRepositoryContents(RepositoryFunction.java:333)
at com.google.devtools.build.lib.rules.repository.NewLocalRepositoryFunction.fetch(NewLocalRepositoryFunction.java:41)
at com.google.devtools.build.lib.rules.repository.RepositoryDelegatorFunction.compute(RepositoryDelegatorFunction.java:82)
at com.google.devtools.build.skyframe.ParallelEvaluator$Evaluate.run(ParallelEvaluator.java:933)

Not sure why that's necessary, as opposed to just symlinking the
directories. @kchodorow?

> https://groups.google.com/d/msgid/bazel-discuss/83f28fbe-19cf-44b1-b0de-53fe20fafc25%40googlegroups.com.

[Kristina Chodorow]

They're individually symlinked so that we can add a BUILD file in the directory. Theoretically we could do this differently (e.g., put the BUILD file and a symlink to the path in the same directory and then make people refer to everything relative to the basename of the path), but we don't at the moment.  If /usr/lib or /usr/lib/x86_64-linux-gnu/something/more/specific has fewer files, you could try using that as the path to speed things up.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAF7sfHAQJWvCSi4700ooFfQOPrDRAu2N%2B4dL%2B51Qi8Y0rCJaRQ%40mail.gmail.com.

[Onath Claridge]

Aha, thanks for the suggestion! It looks like basing the repo at /usr is the thing to do. Not only does that dodge the too-many-files problem (hopefully that's true for everybody else running our build, too...), but it lets me make single libraries that span /usr/include, /usr/local/include, and /usr/lib/x86_64-linux-gnu.