Does anyone know of any tricks to speed up Remote Debugging? I mostly develop on Windows and use the Remote debugger stub on my Mac to run/test it there. The Application MyApp.debug.app.tar.gz file gets built and sent over the network pretty fast, about 7 seconds. But then it takes another 11 seconds just to see the uncompressed, MyApp.debug.app.tar file appear…then another 2 or so seconds for the app to fire up.
The bottleneck appears to be unpacking the .gz file. This used to be a lot faster on RealBasic on my setup. Does anyone have any tricks for speeding this up? Maybe I don’t things properly setup to unpack it quickly?
Strange. I do the reverse - develop on Mac and deploy to Win. It typically takes 20 seconds to get the remote debug app running in a Windows VM. It used to be much quicker only a few Xojo versions ago. I thought it was because of the additional DLLs added in 2014 for dates/text/etc. This on a 3.4 Ghz I7 with SSD.
Maybe Xojo is pushing these additional libs to Mac debug sessions from Win?
I’m running 2014r2.1, which doesn’t have the big increase in DLLs. I noticed the big jump in the amount of time it took from the last version of RB to the first of version Xojo last year. I brought it up with Tech Support and they said they thought things should be speeding up…I’m sure not seeing it. It gets tarred and zipped, and across the network pretty fast, its when it unpacks is the issues. I have an SSD on both computers.
I have seen this behaviour when you have a console or web application running on XP target and it does not matter if running locally or remotely by debugger.
This startup delay does not happens when running on Win7.
OSX is the target, not XP and I have nothing running there. As I mentioned, the .gz file gets there fairly quickly, just takes 11 seconds to decompress it, and this is not a large project by any stretch.
Sorry, when you said XP , I thought you meant Windows XP was the target. It is a problem on the Target, OSX in this case. The app is built, the .gz file is created and it gets across the network and appears on the Desktop of the Target OSX machine in 7 seconds. More than reasonable performance. But takes 11 seconds to unpack it. That is the problem.
I don’t have anything running on the target OSX machine other than the remote debugger stub.
If you measuring the time from when the progress bar reaches 100% on the IDE, then that’s the problem. That progress bar represents “bytes sent” to the socket. The socket still has to send the data to the stub, which needs to send back an acknowledgment. In my experiments, I estimate that the transfer time actually takes about 75% longer than the progress bar indicates.
For what it’s worth, the Xojo Cloud uploader (if you use it) displays the amount of data received by the server as indicated by returned ack packets. It makes the protocol slightly slower, but shows a very accurate progress bar.
No, I’m counting the time from when the Remote Debug command is issued from the Menu or the Hotkey combination, Ctrl-Alt-R. I’ll experiment with it some more, maybe it is showing on the desktop but still finishing up transferring. The thing of note here is it much slower in Xojo than it ever was in RB. It went from around 10 seconds to 20 seconds for the same project under RB compared to Xojo. It has remained around 20 seconds in Xojo under every version.
do me a favor and check 2012r2. That’s when we added gzip compression. I’d also be curious about versions prior to that. In my experience gzip cut transmission speeds by ?, especially over vpn connections to a remote location.
I only have 2102r2.1, but that’s not the big problem. This project has been converted to SQLite, so the old version in RB won’t run. I don’t have time right now to dig out the old files and move things around, have a deadline coming up in a week. I did try a smaller project that didn’t have any database ties, and it went faster, but of course the tarball was much smaller. Just let it go for now, I’ll have to try this later when I have some time. But thanks for the help.
Are you transferring a database for remote debugging? If so, I would put a database on the remote machine and use #if DebugBuild statements for debugging. Sending the same file over and over again is a waste of your time.
I tend not to include databases in my remote debugging to speed it up. Even if that means it’s not a ‘true’ build. If time is money and waiting for a transfer is the bottleneck, eliminate as much of the transfer as possible.
Other things:
Is the remote computer a regular drive or SSD? If you can, get a computer with SSD drive and it will significantly speed up delivery/unzip.
Its an SSD on both ends, no problem with that part of. The 3 database files are already over there, but a build copy step is putting them in the resources folder. I guess I can look at that as a way to reduce the size. Thanks, I’ll look at it as soon as I can.
I set the Build Copy Step to only copy the 3 database files to the Resource folder for Release only, so that it is not picked up when debugging and it does help some, about 3 seconds over all. Takes about 18 seconds instead of 21 second. Better, and it is an easy fix, but doesn’t explain the big difference in RB versus Xojo. I’ll have more time to look at this in a couple of weeks I’ll review it then. Thanks for the input.
Yeah, I dunno. I don’t remember when it happened but I know there was a version of Remote Debugger Stub for Windows that dramatically sped up remote debugs from Mac to Windows. I think that’s the gzip compression that Greg’s talking about. Since I don’t do it the other direction I can’t really help you.
I’d submit a Feedback report explaining the situation. Perhaps something changed in a socket class that’s causing the slowdown and the IDE isn’t using it as efficiently as it could.
When I build the OSX version on Windows the app is about 16.5 MB. When I take out the 3 database files as Bob suggested earlier it is 14 MB. Similar sizes when I build directly on the Mac.
If using Gig ethernet or a VM, the transfer speed of 30-50, even 100 MB should be negligible. So it seems like a lot of time is spent zipping then unzipping the files, while a straight file transfer would seem to be much faster.
Although it may not help in every situation, an option to disable zipping may make debugging much quicker.
[quote=160633:@Tanner Lee]If using Gig ethernet or a VM, the transfer speed of 30-50, even 100 MB should be negligible. So it seems like a lot of time is spent zipping then unzipping the files, while a straight file transfer would seem to be much faster.
Although it may not help in every situation, an option to disable zipping may make debugging much quicker.[/quote]
Keep in mind that more code is included in the build when debugging, and that the protocol for transferring an app for remote debugging is not a simple TCP transfer. I suspect that the majority of the time is spent combining the parts of the build into a single file. Remember, gzip doesn’t compress folders. We have to use another format (like TAR) to get all of those pieces into a single file first, and we need to do this regardless of whether we’re going to compress it. If you’ve ever downloaded the source code for an app on OS X or Linux, you may have noticed that it had a .tgz or a .tar.gz extension. That’s what this is.
All that said, until yesterday there wasn’t a feedback case about this (which I filed myself because there wasn’t one) and looked into it, and it looks like there is more room for some improvement.
One thing to keep in mind… Remote Debugger Stubs before v1.9 did not support gzip compression, and there was very little done at that time. You could certainly grab the stub from IDE version 2012r1 and try that out if you’d like to see what the transfer is like without gzip.