6.0.3 * Fixed unnecessary UI locking caused by filesystem refresh

Which issue # is this one in the tracker? I didn't see it in any of the notes.
Thanks, Jon

0
Avatar
Permanently deleted user

Hello Jon,

JS> Which issue # is this one in the tracker? I didn't see it in any of
JS> the notes. Thanks, Jon

I think we don't have any JIRA issue for this change.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Avatar
Permanently deleted user

Jon, we really didn't make the issue for this.
Eugene.

0
Avatar
Permanently deleted user

Wow, synchronization is barely noticeable any more. Eugene, you're my hero ;)

Sascha

0
Avatar
Permanently deleted user

Sascha,
it was Max who hammered this last nail, so please address all applauses to him:)

0
Avatar
Permanently deleted user

Well, this was good teamwork then and the donuts go to both of you ;)

Sascha

0
Avatar
Permanently deleted user

I agree, it really does make a big difference here. This fix means I can
now enable "Synchronize files on frame activation" even though all my source
code lives on a network drive. Fantastic, thanks so much for your efforts
on this.

Well, this was good teamwork then and the donuts go to both of you ;)

Sascha



0
Avatar
Permanently deleted user

From my understanding the update takes place now on a different thread, which allows editing at the meantime.
What about build? Is it enabled before the synchronization has ended?
What happens if I invoke a build before synchronization has finished? I'm concerned about files that need to be updated, but the synchronization thread didn't get to them yet.
Does the building thread take care of this, and will make sure to use the updated file, or will it use the file from cache?

0
Avatar
Permanently deleted user

Build process will trigger second synchronization, that will (or at least might) run in parallel with the first, and pick the later changes.

0
Avatar
Permanently deleted user

Hello Yalon,

YL> From my understanding the update takes place now on a different
YL> thread, which allows editing at the meantime.

This is not true. The synchronization has always been performed in a different
thread. What has been fixed is that some operations on the UI thread unnecessarily
waited on a lock until the synchronization on the background thread was complete.

YL> What about build? Is it enabled before the synchronization has
YL> ended?
YL>
YL> What happens if I invoke a build before synchronization has
YL> finished? I'm concerned about files that need to be updated, but the
YL> synchronization thread didn't get to them yet.
YL>
YL> Does the building thread take care of this, and will make sure to
YL> use the updated file, or will it use the file from cache?

The build is done using javac, which always reads the files from disk and
not from the IDEA cache, so the behavior of the IDEA synchronization thread
doesn't affect this at all.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Avatar
Permanently deleted user

The build is done using javac, which always reads the files from disk and
not from the IDEA cache, so the behavior of the IDEA synchronization thread
doesn't affect this at all.


Not quite true. Build is comprised of invoking multiple compilers (javac, UI designer, Notnull, resources, custom languages, ...), to process changed files correctly make process issues VFS refresh after each stage.
If there was a refresh already running, then several synchronizations could run in parallel, but it indeed this was always allowed.

0
Avatar
Permanently deleted user

The build is done using javac, which always reads the
files from disk and not from the IDEA cache, so the
behavior of the IDEA synchronization thread
doesn't affect this at all.


Even if you choose to use the Eclipse compiler? If yes, maybe it's time for JetBrains to work on a compiler (probably extending ecj) that can work directly from IDEA's caches.

0
Avatar
Permanently deleted user

Since I doubt that the Eclipse compiler has an IDEA-VFS interface, it's probably reading directly fróm the filesystem as well.

I think the JetBrains compiler has had its try, but was abandoned quite some time ago (IIRC it was named "IntelliJac").

Sascha

0
Avatar
Permanently deleted user

I think it's pretty easy to get javac to read files from memory, at least in java 6.

0
Avatar
Permanently deleted user

The problems with this approach are
1) there could be too many files to load them all to memory (reading some compressed data from local vcs I presume) at once to make compiler happy.
Partitioning the compiler chunks to smaller ones based on source interdependency does not seem feasible (too great potential of compilation slowdown)
2) we need to support all versions before javac 6.0

0
Avatar
Permanently deleted user

The problems with this approach are
1) there could be too many files to load them all to
memory (reading some compressed data from local vcs I
presume) at once to make compiler happy.


1. It seems to me that the policy would be "use in-memory file data if present, otherwise fall back to disk" - IDEA does keep lots of files in memory, doesn't it?

2) we need to support all versions before javac 6.0


This could surely only be used if you're using java 6.

0
Avatar
Permanently deleted user

Negligible ratio of file contents is present in memory to account this for performance optimization.

0
Avatar
Permanently deleted user

Wow, nice fix, Jetbrains! No more waiting for the file sync each time I execute an Ant task.

Now if you could stop the "Message - Ant Build" window from grabbing the focus upon completion from my Editor Pane, this would be perfect.

0
Avatar
Permanently deleted user

Further clarification about the focus grabbing.

I have a shortcut assigned to my Ant compile and deploy targets.
I have "Make build in background" enabled for my ant build.xml file.
As soon as I invoke the compile task with the keyboard shortcut,
the focus gets grabbed by the "Messages - Ant Build" window.
If I click back on the Editor pane, and continue working, when the
compile task finishes, the focus is grabbed again by the
"Messages - Ant Build" window. This is pretty annoying.

Ideally, I don't even want the "Message - Ant Build" panel to popup because this is disruptive also. A indeterminate progress bar should show up in the status
bar similar to the background find in path search. Maybe have option to only
display "Message - Ant Build" on error?

Also, the "Parsing files..." modal dialog is still popping up sometimes
after a compile, so I guess there is still more work to put all processing
fully in the background.

-Alex

0

请先登录再写评论。