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.

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.

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.

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.

Re: Lets talk about the long deploying time
 

Do you know if it's possible to automatically fall back to static IP?

Re: Lets talk about the long deploying time
 

You could add a static route to your hosts file

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

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.

Re: Lets talk about the long deploying time
 

Yup.

Thats one of the infinite downsides to using labview. We really need to switch soon!!

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

Re: Lets talk about the long deploying time
 

The deploy stuff is in the Eclipse plugins project

Java deploy tasks are here (build.properties and build.xml)

C++ here

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

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).