Slow opening of new editors

It's not a known issue (it opens instantly for me here).

Now, that can depend on a number of things:

- The 1st opened editor can take more time, because that's when Pydev related things are loaded

- If you have Pydev Extensions, opening a file can trigger an analysis (so, the analysis might be what's slowing it down -- although it should run in a separate, lower priority thread, so, this shouldn't really make a difference for you).

Now, to diagnose it better I need some info:

- Is it related to a specific module in your case (like, opening an empty editor takes the same amount of time)?

- How much RAM memory do you have allocated (through the -Xmx flag) and how much memory is your process using?

- This happens when running only eclipse or do you have some other process that could be dragging your system? (e.g.: once I had a case where I had a database running in my machine and disk access became very slow for a number of other things -- some antivirus can have that effect too)

- Are you using only Pydev or Pydev Extensions too?

Cheers,

Fabio

I'm using raw PyDev, without PyDev Extensions, with completely clean pristine Eclipse installation.

_Every_ new editor (not just the first one) is slow. And for a few seconds when I try to open a file, the new editor's tab is named 'PyDev Editor'.

I've tried to turn off analysis and code folding but it doesn't seem to have any effect. And it's slow even on 'hello world' project.

The operating system I use is Linux, and CPU load is negligible when Eclipse is running. There's also a lot of free memory (-Xmx is 512M) and no disk activity at all.

Other project types (C++ and Java) work normally. Apart from this issue PyDev also works fine (debugging, autocomplete, etc.)

I've tried to strace PyDev, but without results. Is there any code in PyDev which might try to resolve hostnames or something like it?

I've tried several Sun JVMs as well as IcedTea JVM.

My machine also has IPv6 configured, so it might cause this problem. Loopback interface is up and running both in IPv6 and IPv4 stacks. I'll try to disable IPv6 tomorrow and see what happens.

Yes, disabling IPv6 works. I'm trying to figure out why it matters.

Found the problem.

IPv6 used incorrect MTU (1500 instead of 1492) for eth0 interface, which caused a slowdown while TCP negotiated the transfer window.

Now the question: why does it try to use eth0 interface?