I have a open source project and the counter of files in project are more than 40.
I build the project when the configuration is Debug and the compile time is 2m22s.
And I also use the BuildTimeAnalyzer, the longest time of all is 28ms.
But when I build the project with the Release configuration, it stuck in Compile Swift source files more than one hour.
I have no idea about this, please help me.
In the DEBUG build, if you add up all the time spent on each function, you get about 7s. The numbers don't quite add up — you have spent 142s to build the whole thing, but these functions just take about than 7s to compile??
That's because these timing just accounts for type-checking each function body. In the Swift frontend there are three flags you could use:
-Xfrontend -debug-time-compilation
-Xfrontend -debug-time-function-bodies
-Xfrontend -debug-time-expression-type-checking
Let's use the first to see the whole picture. Pick one slow file, say Option.swift, and look:
===-------------------------------------------------------------------------===
Swift compilation
===-------------------------------------------------------------------------===
Total Execution Time: 30.5169 seconds (43.6413 wall clock)
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
23.5183 ( 80.1%) 0.7773 ( 67.6%) 24.2957 ( 79.6%) 34.4762 ( 79.0%) LLVM output
3.7312 ( 12.7%) 0.0437 ( 3.8%) 3.7749 ( 12.4%) 5.4192 ( 12.4%) LLVM optimization
1.8563 ( 6.3%) 0.2830 ( 24.6%) 2.1393 ( 7.0%) 3.1800 ( 7.3%) IRGen
0.2026 ( 0.7%) 0.0376 ( 3.3%) 0.2402 ( 0.8%) 0.4666 ( 1.1%) Type checking / Semantic analysis
... <snip> ...
29.3665 (100.0%) 1.1504 (100.0%) 30.5169 (100.0%) 43.6413 (100.0%) Total
Turns out it's not Swift that is slow, but LLVM! So there is not point looking at type-checking time. We can further check why LLVM is slow using -Xllvm -time-passes, but it won't give us useful information, it's just saying X86 Assembly / Object Emitter is taking most time.
Let's take a step back and check which files take most time to compile:
Option.swift 30.5169
Toolbox.swift 15.6143
PictorialBarSerie.swift 12.2670
LineSerie.swift 8.9690
ScatterSerie.swift 8.5959
FunnelSerie.swift 8.3299
GaugeSerie.swift 8.2945
...
Half a minute is spent in Options.swift. What's wrong with this file?
You have a huge struct, with 31 members. Compiling that struct alone takes 11 seconds.
You have a huge enum, with 80 variants. Compiling this enum alone takes 7 seconds.
The first problem is easy to fix: Use final class instead! The second problem would not have a simple fix (I don't see any time improvement with alternatives e.g. replace the enums with class hierarchy). All other slow files have a similar problem: large structure, large enums.
Simply replacing all struct with final class is enough to bring the compilation time from "over hours and still compiling" to "2.5 minutes".
See also Why Choose Struct Over Class?. Your "struct"s may not qualify as structs.
Note that changing from struct to class do change the semantics of users' code since classes have reference semantics.
Try this....
under Build Settings -> Swift Compiler - Code Generation for your Release choose SWIFT_OPTIMIZATION_LEVEL = -Owholemodule. Then under Other Swift Flags enter -Onone. Doing this carved off big chunks of time off my project.
Related
I have already installed the both plugins but don't know how to use them for pod analysis. Need help in that as i don't have programming background. Also can we use it for batch processing of images, in case i have more than 100 images?
Another approach per specially coded ImageJ-macro gives reasonable estimates of the widths and lengths of all pods in the sample image. You can access the macro code from here. Unzip the zip-archive and drop the file "plantPodDimensions.ijm" onto the ImageJ main window. Then open the sample image and run the macro. The estimated pod dimensions appear in a table.
Specimen [right to left] Mean Pod Width [cm] Pod Length [cm]
OHiI7_pod-1 0.70±0.11 23.6
OHiI7_pod-2 0.59±0.09 22.3
OHiI7_pod-3 0.64±0.05 20.7
OHiI7_pod-4 0.41±0.04 20.5
OHiI7_pod-5 0.66±0.07 22.9
OHiI7_pod-6 0.68±0.10 24.4
OHiI7_pod-7 0.60±0.07 20.5
Of course it couldn't be tested, if the macro works as expected for other images than the sample image.
With the download of the plugins come documents that explain the use of the plugins. Batch processing is possible, if the starting points of the traces are known or can somehow be determined by additional pre-processing steps (not trivial). Both plugins are macro-recordable. In any case, batch processing will require some macro code.
For the use case in question I would recommend to perform the analyses via the GUI, not per batch processing. The coding of a suitable macro would take more time than the processing of 100+ images.
Working with the source code from AOSP, after I make a trivial change to a
source file under frameworks/base/core/java/android/,
mmm frameworks/base -j9 takes about 4 minutes.
A large portion of that time seems to be waiting for steps with names containing "Droiddoc" or "Docs droiddoc" to complete:
...
[ 14% 4/28] Docs droiddoc: out/target/common/docs/api-stubs
[ 21% 6/28] //frameworks/base:test-api-stubs-docs Droiddoc [common]
DroidDoc took 102 sec. to write docs to out/soong/.intermediates/frameworks/base/test-api-stubs-docs/android_common/docs/out
[ 28% 7/25] Docs droiddoc: out/target/common/docs/api-stubs
DroidDoc took 113 sec. to write docs to out/target/common/docs/api-stubs
[ 32% 8/25] //frameworks/base:api-stubs-docs Droiddoc [common]
DroidDoc took 115 sec. to write docs to out/soong/.intermediates/frameworks/base/api-stubs-docs/android_common/docs/out
[ 40% 9/22] //frameworks/base:system-api-stubs-docs Droiddoc [common]
DroidDoc took 117 sec. to write docs to out/soong/.intermediates/frameworks/base/system-api-stubs-docs/android_common/docs/out
...
I really don't need or want any documentation to be built on every little incremental recompile.
Is there a way to omit all these doc-related steps?
I'd be interested in either a command line flag if there is one,
or a hopefully simple hack to one or more Makefiles and/or .mk files.
I've looked through the .mk files; in particular build/make/core/droiddoc.mk
seems relevant. I tried cutting some wires in it without really understanding what I was doing, without success.
I'm hoping someone who understands how these .mk files are put together
will know how to do this easily.
I expect this will be of interest to anyone who runs mmm frequently.
During make or mmm invocations, there are apparently two different kinds of build steps that build docs.
Each must be dealt with in its own way.
The build steps that have "Docs droiddoc" in their progress messages. That string comes from build/make/core/droiddoc.mk.
I was able to suppress these build steps as follows: delete all lines from build/make/core/droiddoc.mk, so it becomes an empty file.
The build steps that have "Droiddoc" in their progress messages. That string comes from build/soong/java/droiddoc.go.
I was able to suppress these build steps as follows: delete or comment out the last two blocks in the calling file build/soong/java/androidmk.go:
func (jd *Javadoc) AndroidMk() android.AndroidMkData {
...
}
func (ddoc *Droiddoc) AndroidMk() android.AndroidMkData {
...
}
I confirmed that it's no longer spending time building docs, on Darwin, by keeping an eye on the Activity Monitor during the build,
and verifying that javadoc processes no longer appear.
With docs omitted, mmm frameworks/base -j9 after a small code change now takes 45 to 55 seconds, instead of 4 minutes.
I am trying to get familiar with gem5 simulator.
To start, I wrote a simple program with
int main()
{
m5_reset_stats(0, 0);
m5_dump_stats(0, 0);
return 0;
}
I compiled it with util/m5/m5op_x86.S and ran it using...
./build/X86/gem5.opt configs/example/se.py --caches -c ~/tmp/hello
The m5out/stats.txt shows (among other things)...
system.cpu.dcache.ReadReq_hits::total 881
system.cpu.dcache.WriteReq_hits::total 917
system.cpu.dcache.ReadReq_misses::total 54
system.cpu.dcache.WriteReq_misses::total 42
Why is an empty function showing so much hits and misses? Are the hits and misses caused by libc? If so, then what is the purpose of m5_reset_stats() and m5_dump_stats()?
I would check in the stats.txt file if there are two chunks of
---Begin---
---End-----
because as you explained it, the simulator is supposed to dump the stats at dump_stats(0,0) and at the end of the run. So, it seems like you either are looking at one of those intervals (and I would expect the other interval to have 0 for all stats); or there was a bug in the simulation and the dump_stats() (or reset_stats())didn't actually do anything. That actually happened to me plenty of times, but I am not really sure as to the source of this bug.
If you want to troubleshoot further, you could do the following:
Look at the disassembly of your code and find the reset_stats.w and dump_stats.w
Dump a trace from gem5 and see if it ends up executing the dump and reset instructions and also what instructions (and how many) are executed before/after.
Hope this helps!
I'm using EF6 rc1 with Code First strategy, without precompiled views and the problem is:
If I compile and run the exe application it takes like 15 seconds to run the first query (that's okay, since I'm still working on the pre-generated views). But if I use Visual Studio 2013 Preview to Debug the exact same application it takes almost 2 minutes BEFORE running the first query:
Dim Context = New MyEntities()
Dim Query = From I in Context.Itens '' <--- The debug takes 2 minutes in here
Dim Item = Query.FirstOrDefault()
Is there a way to remove this extra time? Am I doing something wrong here?
Ps.: The context itself is not complicated, its just full with 200+ tables.
Edit: Found out that the problem is that during debug time the EF appears to be generating the Views ignoring the pre-generated ones.
Using the source code from EF I discovered that the property:
IQueryProvider IQueryable.Provider
{
get
{
return _provider ?? (_provider = new DbQueryProvider(
GetInternalQueryWithCheck("IQueryable.Provider").InternalContext,
GetInternalQueryWithCheck("IQueryable.Provider").ObjectQueryProvider));
}
}
is where the time is being consumed. But this is strange since it only takes time in debug. Am I missing something here?
Edit: Found more info related to the question:
Using the Process Monitor (by Sysinternals) I found out that there its the 'desenv.exe' process that is consuming tons of time. To be more specific its consuming time with an 'Thread Exit'. It repeats the Thread Exit stack 36 times. I don't know if this info is very useful, but I saved a '.cvs' with the stack, here is his body: [...] (edit: removed the '.cvs' body, I can post it again by the comments if someone really think its going to be useful, but it was confusing and too big.)
Edit: Installed VS2013 Ultimate and Entity Framework 6 RTM. Installed the Entity Framework Power Tools Beta 4 and used it to generate the Views. Nothing changed... If I run the exe it takes 20 seconds, if I 'Start' debugging it takes 120 seconds.
Edit: Created a small project to simulate the error: http://sdrv.ms/16pH9Vm
Just run the project inside the environment and directly through the .exe, click the button and compare the loading time.
This is a known performance issue in Lazy (which EF is using) when the debugger is attached. We are currently working on a fix (the current approach we are looking at is removing the use of Lazy). We hope to ship this fix in a patch release soon. You can track progress of this issue on our CodePlex site - http://entityframework.codeplex.com/workitem/1778.
More details on the coming 6.0.2 patch release that will include a fix are here - http://blogs.msdn.com/b/adonet/archive/2013/10/31/ef6-performance-issues.aspx
I don't know if you have found the solution. But in my case, I had similar issue which wasted me close to a week after trying different suggestions. Finally, I found a solution by changing my web.config to optimizeCompilations="true" and performance improved dramatically from 15-30 seconds to about 2 seconds.
I have a quick question about the details of running a model in JAGS and BUGS.
Say I run a model with n.burnin=5000, n.iter=5000 and thin=2. Does this mean that the program will:
Run 5,000 iterations, and discard results; and then
Run another 10,000 iterations, only keeping every second result?
If I save these simulations as a CODA object, are all 10,000 saved, or only the thinned 5,000? I'm just trying to understand which set of iterations are used to make the ACF plot?
With JAGS, n.burnin=5000, n.iter=5000 and thin=2, means you keep nothing. You run 5000, discard the first 5000 of these 5000 and then only keep a half of the remaining values of the chain (keep 1 value and discard the next one ..).
Use for example n.burnin=2000, n.iter=7000, thin=50, n.chains=5 : so you have (7000-2000)/50 * 5 = 500 values.
Could you be more specific which software you're talking about? It looks like you're referring to the arguments of the function bugs() in the R2WinBUGS package (except that the argument is called n.thin not thin). Looking at help(bugs) it just says n.burnin is the "number of iterations to discard at the beginning". Which doesn't specifically answer your question, but looking at the source for bugs.script() in that package suggests to me that it would run 5000 iterations burn in, as you suspected. You could send a suggestion to the maintainers of that package to clarify their documentation.
In your example, bugs() would then run 0 further iterations after the burn-in. Here the documentation is clearer - n.iter is the total number of iterations including the burn-in.
For your second question, the CODA output from WinBUGS (and any software which calls WinBUGS or OpenBUGS) will only include the thinned sample.