Author Topic: SlickEdit Over VPN: Project Takes Forever To Build  (Read 4264 times)

gbaker

  • New Community Member
  • Posts: 1
  • Hero Points: 0
SlickEdit Over VPN: Project Takes Forever To Build
« on: May 03, 2008, 03:21:39 PM »
I've been doing lots of remote computing lately (using Citrix which was driving me crazy). My employer recently set me up with a VPN access point which I thought would make my life much better, however SlickeEdit doesn't seem to play well with the VPN setup.

For some reason directory listings (not just slickEdit, but in general) seem to take a very long time over the VPN. I've heard that this is a known problem with Windows. The effect on SlickEdit is that when I try to create a project and add files (using add tree), it takes for bloody ever. Merely finding the files in one directory seems to take 15 minutes or so, then building the tag file takes about 30 minutes.

Given that I have to add multiple directories this just won't work.

I'm wondering if there's a smart cool way that I can login to a machine that's on the site (using Citrix), use SlickEdit on that machine to build the project and tag files, and then transfer the results to my home machine. I suspect that this can be done, but I also suspect that there would be some nit picky details:

  • I'm not sure what files I would need to transfer and where I would put them.
  • I suspect that there might be some issues with directory paths, i.e. the path to a file on the company machine might be different than the path on my local machine

I'm hoping that somebody might have already run down this road before and can at least provide a helpful tip or two!

jimlangrunner

  • Senior Community Member
  • Posts: 360
  • Hero Points: 31
  • Jim Lang - always a student.
Re: SlickEdit Over VPN: Project Takes Forever To Build
« Reply #1 on: May 05, 2008, 10:36:50 AM »
I don't know what your environment is (aside from Windows), so I may not cover all of the bases here, but I'll give it a shot. 

When I need to work remotely (from home, mostly), I use remote Desktop through the VPN to do most of the work I do.  If it's something that will take some time, or that lag will be an issue (as is it appears to be with you), I simply xcopy the changed files to my home machine & work on it from there.  XCopy is a wonderful thing.

Considerations:
  • I have the same dev tools installed at home (including SlickEdit!)
  • I have the same DLLs and ActiveX controls installed at home as at work
  • I have my projects set up with relative paths.  All hard-coded paths have been take out back and shot, along with the developers that think it's a good idea.
  • I have configuration settings (SQL connection strings) off on their own so they're not overwritten

Of course, you Slick config and project/workspace files are portable already (I HOPE!) and are fairly easy to check (.vpg and .vpw, respectively) as they're plain text files. 

That's about it.  Hope it helps.
Jim

MichaelBrenden

  • Community Member
  • Posts: 13
  • Hero Points: -1
Re: SlickEdit Over VPN: Project Takes Forever To Build
« Reply #2 on: February 16, 2013, 02:24:25 AM »
identical problem here - extremely slow when coding remotely.

windows appears to send hundreds if not thousands of tiny payload packets (150 bytes vs 1500 bytes TCP spec allows), which hikes up overhead.

discovered that during the resulting prolonged chatty idiocy that ANY lost packet would force the whole conversation to restart (vs just resending the lost tiny packet(s)), we changed the openvpn tunnel protocol from the recommended UDP to TCP, which helped but not much as we'd hoped.

this does not appear to be a slickedit problem at all, but this windows problem severely affects all remote work, particularly regarding file operations (open directory, list contents, get/put files).

of course micro$oft offers another product to fix its self-made idiocy, something called branchcache.  of course since we only use ms stuff we can't otherwise escape, we'll never use this, no matter what, and would build dozens of servers and hire extra help, before we invested anymore in anything special, especially to solve self-invented problems.  as always, the real culprit is windows.

so this is part venting and part warning.  if you're planning to do remote coding on large codebases (hundreds or thousands of files, multiple projects), think again.  local LAN 'test' server is the only feasible option.