|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
|
Lets talk about the long deploying time
I am using java to deploy code to the robot and it's taking about half a minute to deploy in the best case scenario. Before 2017 season it was 15 - 20
now it's not a reasonable run time, I mean I didn't check the build process but running a fresh code which takes about 40 sec can surely be reduced. Does it copy all the 3rd party lib into the robot every time? I am intrested in hearing your thoughts guys and build time on your programming language. |
|
#2
|
||||
|
||||
|
Re: Lets talk about the long deploying time
I have also noticed an odd increase in Java deployment time this year. In 2013 it took around 30 seconds, 2014 down to 20-25ish, and 2015 was down to times around 10 seconds. I am not sure about last year's average time, but this year our deploy times have all been longer than 30 seconds. One possible reason is that we are also deploying a CAN library for our speed controllers this year, but I doubt it's the sole reason, and I'm not sure of any other reasons off the top of my head.
|
|
#3
|
||||
|
||||
|
Re: Lets talk about the long deploying time
This year's deploy scripts makes more ssh calls than it previous made, and if your mDNS resolving isn't particularly fast, it might be the cause. You can test this (ish) by opening a command prompt and doing a 'ping' of roborio-XXXX-frc.local, where XXXX is your team number, if it takes awhile for it to figure how to resolve that address, that could be the culprit.
|
|
#4
|
||||
|
||||
|
Re: Lets talk about the long deploying time
Regardless of mDNS lookup times, the additional SSH calls are significant on their own and can easily add at least 1/2 to 2s each to setup/teardown.
I haven't looked at how many more SSH calls there are this year, but I suspect that's a major reason, if not the major reason. |
|
#5
|
||||
|
||||
|
Re: Lets talk about the long deploying time
Quote:
|
|
#6
|
|||
|
|||
|
Re: Lets talk about the long deploying time
You could add a static route to your hosts file
|
|
#7
|
||||
|
||||
|
Re: Lets talk about the long deploying time
GradleRIO has recently been updated to be 2017 compatible. Deploy times are anywhere from 5-15 seconds. For each deploy, there are only 3 ssh sessions (one for discovery, one for NI utils, one for user code), and libraries are only deployed if they have changed or have not been deployed before (e.g. wpilib, opencv, talonsrx, cscore, etc).
You can see the project here: https://github.com/Open-RIO/GradleRIO |
|
#8
|
||||
|
||||
|
Re: Lets talk about the long deploying time
I use LabVIEW and one simply edit to your code and you have to build it and Run as startup. This take about 3-5 minutes but one main issue is you have to sit next to your computer due to a couple of warning messages appearing.
|
|
#9
|
|||
|
|||
|
Re: Lets talk about the long deploying time
Quote:
Thats one of the infinite downsides to using labview. We really need to switch soon!! |
|
#10
|
||||
|
||||
|
Re: Lets talk about the long deploying time
If you really want to, you could submit an issue or pull request to the official WPIlib. Clearly, as Jaci points out, it could be faster with the right code.
https://github.com/wpilibsuite/allwpilib |
|
#11
|
||||
|
||||
|
Re: Lets talk about the long deploying time
Quote:
Java deploy tasks are here (build.properties and build.xml) C++ here |
|
#12
|
|||
|
|||
|
Re: Lets talk about the long deploying time
Specifically for LV users. I just tested the default code which includes vision acquisition and analysis.
A build was 25 seconds. A Run as Startup was 18. The first time I did these things on my new installation it was longer because it is building more things and caching them. The interactive deploy (pressing the run button) was about 60 seconds when the target was running something else that needed to be canceled. It was 20 seconds on a target where the VIs were reloaded but the target had them cached. The interactive run was 3 seconds for small changes where the Main VI was not closed. This was on an i5 several years old - $400 laptop. Greg McKaskle |
|
#13
|
||||
|
||||
|
Re: Lets talk about the long deploying time
One thing I found is that using a manual DNS server (8.8.8.8 & 8.8.4.4 for me) made the lookup take significantly longer (40 seconds with, 10 seconds without).
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|