Why do Cobalt Website Module builds take so long?
***Rant:*** Building Website locally with code analysis on takes 4+ minutes now days. When you finally check in to CI a single Website Platform build (not including products) can take 25+ minutes. ***:End Rant*** I am really just wondering why they have become so bad and if there is anything being done to bring the times down? For both local builds and code check-in builds / deploys. Thanks, Josh
Tagged:
7
Best Answer
-
So I looked into this and as I suspected the bulk of the time is spent compiling views. I think we actually end up compiling the platform views twice. The first time we build them is when we build Cobalt.Website.Platform.Web, about 1.5 minutes of building that project is spent building the views. Then as a post build step of the WestlawNext.Web project I think we again building the views. About 1.8 minutes during the build of that project are spent on an Exec task which I think includes building all the views. A few months ago we added building the views as part of the Debug/Release builds. The reason we added building the views was to find coding issues in the views at build time rather than run time. This is especially helpful when we are making platform changes that could end up affecting views in multiple products. Note that all the tasks are not listed in the tables below, just the last few that take most of the time. Times from Cobalt.Website.Platform.Web:
Time (ms)Task# of Calls105Copy4209ResolveAssemblyReference1428RemoveDir23167Csc13454StyleCopTask115985CodeAnalysis190769AspNetCompiler1
Times from WestlawNext.Web:
Time (ms)Task# of Calls332ResolveAssemblyReferences1685CoreCompile1850StyleCop15580RunCodeAnalysis1108824PostBuildEvent15
Answers
-
Well... Running the builds with Code Analysis does a lot of things. It runs a full StyleCop analysis as well as a full Microsoft CA on literally thousands of files - and then after all that, we recently added a view verification so view failures won't make it to CI and break the environment. There are probably other things running as well as part of the post-build processes and I won't pretend to know them all. I'd love it if the builds ran faster as well, but that means we have to remove something. If we remove one of the actual Code Analysis, then we end up with bad standards and inefficient code. If we remove the view verification, then we end up with broken environments when people don't verify their changes locally. You could always try begging for a faster computer with a SSD, maybe (if you succeed, I may try and follow suit)?6
-
What are the current specs on the build machines?0
-
You make valid points Kevin its just getting to a point where it takes upwards of half a day to check in. As far as SSDs go, we ran some tests locally with Laptops 8GB RAM with SSDs, Desktops 8GB RAM with SSDs, iMac with 16GB of RAM and Desktops 8GB RAM without SSDs. The iMac seemed to be the only one with noticeably faster Website builds (with CA on).0
-
So maybe you need more RAM or to increase the size of your page file (basically virtual memory) on Windows?0
-
For the record, though, I agree: Website builds are insanely slow and it also takes me hours to check-in "correctly" more frequently than not.0
-
The platform web project is by far the worst project to build taking nearly 3 minutes of the total 5.5 minutes it takes me to build. Something about that code is causing the Code Analysis to take much longer than other projects. The lines of code and cyclomatic complexity below were gathered by right clicking on the solution and clicking Calculate Code Metrics. The timings were gathered by Tools -> Options -> Projects and Solutions -> Build and Run and changing MSBuild project build output verbosity to Normal. This setting can be upped to Detailed and Diagnostics so perhaps if somebody has time, they can take an even closer look to see what is taking so long. ![Website Build Stats][1] [1]:
http://techoverflow.int.thomsonreuters.com/upfiles/WebsiteBuildStats.png5 -
Nice initial investigation, that does indeed seem strange.0
-
If we are compiling most of the same views twice is it possible to only compile the views once?0
-
Yes, we will be checking that change in to 20.70
-
Website has now been changed to no longer build the platform views as part of the cobalt.website.platform.web project.0
-
Not an answer, but a workaround: you can always unload unit/integration test projects if you are just testing against the environment.1
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛