not seeing all the build timings
hixfield opened this issue · comments
I clean my project (even the derived data). Startup the build time analyzer and hit build. I see different source code files popping up with their timing in the build time analyzer window, but then quickly the screen gets cleared and after the build finished only timings are displayed of one particular file (in my case PaintCode.swift).
Hmmm... That sounds odd. Almost as if a second build process starts after the main one.. I'm not sure how to help out without being to able to reproduce it myself. Perhaps one way would be to go to your derived data path and have a look.
~/Library/Developer/Xcode/DerivedData/XXX/Logs/Build/
(where XXX is the product name follow by some identifier by Xcode)
If you sort by date and see two recent log files, one being smaller and more recent than the other, then something is up with the build process. If not, at least then that has been ruled out.
One more thing to check. Does the build duration label (to the upper right) match your actual build duration or is it shorter?
A1: I cleaned my logs directory, did a clean in XCode as well, and started a build. After the build I found the following files in the folder you specified :
B804C842-5888-4FE8-B44C-AE5D5B5CB1BA.xcactivitylog => 08:36 and 267K
4FCA2CF3-3A25-455B-BE19-3315C6F849B2.xcactivitylog => 08:34 and 1K
Cache.db => 08:36 and 1K
A2: the build B.T.A. window says 93 seconds top right, that is correct
Also noticed that if I shutdown the B.T.A. window and start it again (from xcode menu) that also the issue happens being (1) first I see more logs and functions (2)screen clears and is overwritten by only logs from one source file (being PaintCode.swift in my case)
Ok, so the files and build process is fine. If you would be willing to share your 267K log file, I could have a closer look. I haven't encountered this issue myself and don't know how to reproduce it.
Sure I can send you the log file, but privately (not on this public forum), how can I do this?
Drop me an email at robert@canemedia.co.uk and I'll have a look when I have a moment.
done!
Hi. I'm having the same issue, cleaned Derived Data and have only 2 files: Cache.db and XXXX.xcactivitylog. Also, the build duration in the plugin window is wrong, it says 0s.
Either way, thanks for creating / sharing the plugin!
Ok, there is nothing wrong with the log file so I'm not sure why this happens. I'm going to mark this one with 'Help Wanted' by someone who experiences the bug.
To debug this, clone the project and open it up in Xcode. Then go Edit Scheme -> Run. In the Executable field, add Xcode (by navigating to the Applications folder). Then Run the plugin project.
Some process appears to be causing the result to be wiped out. Probably on or after completion (suggested break point on line 26 of CMLogProcessor.swift).
@RobertGummesson if I increase func entries: [CMRawMeasure]) -> [CMRawMeasure] inner limit, more results are displayed. Don't know the best way to fix it, though.
There is no function called entries AFAIK. Did you mean capEntries(entries: [CMRawMeasure]) and then the limit on line 82?
If so, what happens exactly? If the limit is 20, no results are displayed and if you increased it you see a few results?
...and I better direct that to @amg1976 in case you are not a watcher of the project.
Sorry, that was probably auto-correct and I didn't notice it. Yes, if I increase the limit, then more results are displayed.
Interesting. Almost sounds like something goes wrong on line 87. The code in the method looks fine to me though. Not sure what to suggest...
Ah, I have reread this bug with a fresh mind. Maybe this isn't a bug after all (correct me if I am wrong, @hixfield , @amg1976 ). Here is what is happening.
- The log file is being parsed
- You see multiple files while it's processing
- Eventually you see 20 results from the same file.
Correct?
The idea with the plugin is to get an overview of the 20 most time consuming issues. In your case, the entire top 20 is in one file. You will eventually see other files if refactor and improve the build times for these function.
In @hixfield case, it makes sense to refactor PaintCode.swift because that's where the largest issues are and likely the largest contributor to why the project builds so slowly.
If you need to see more results, you can adjust the limit in the capEntries function just as @amg1976 did.
Does that make any sense?
It does make sense, but we are displaying the results in a scrollable table, in my opinion it would be more interesting to display the complete list, but sort it based on time for example (or even better by default on the time column, but user can click any column to sort after this).
Note: PaintCode.swift is an auto generated file and I cant alter this, so this makes the current build of the B.T.A. unusable for me :(
As a quick fix for me I have put the limit = 20000 in the capEntries function, now I am seeing all the entries.
I'll keep that under consideration. The limit has been added to keep the log processing time to a minimum but I haven't benchmarked the process. Perhaps the limit could optional. Will have a think...
Or maybe set it as an end user parameter on the UI?
On Wed, May 11, 2016 at 8:07 AM, Robert Gummesson notifications@github.com
wrote:
I'll keep that under consideration. The limit has been added to keep the
log processing time to a minimum but I haven't benchmarked the process.
Perhaps the limit could optional. Will have a think...—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#10 (comment)
Yep, that's an option...
#10 (comment)
This one also can be handled in #17 :)