Comments on: Waiting On Ill-behaved Software Is Worst Distraction Of All http://tinobox.com/wordpress/stuff-to-do-while-compiling/waiting-on-ill-behaved-software-is-worst-distraction-of-all/ Odds and ends of internet entrepreneurship—A Technical Diary Wed, 15 Feb 2012 09:23:47 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: How Yoga Improves Productivity While Using Computers | There Is NO Box http://tinobox.com/wordpress/stuff-to-do-while-compiling/waiting-on-ill-behaved-software-is-worst-distraction-of-all/comment-page-1/#comment-2709 How Yoga Improves Productivity While Using Computers | There Is NO Box Wed, 06 Oct 2010 22:10:38 +0000 http://tinobox.com/wordpress/?p=118#comment-2709 [...] written on software distraction before. Compiling is probably the worst distraction. There’s even a category here on There Is NO Box [...] [...] written on software distraction before. Compiling is probably the worst distraction. There’s even a category here on There Is NO Box [...]

]]> By: doolin http://tinobox.com/wordpress/stuff-to-do-while-compiling/waiting-on-ill-behaved-software-is-worst-distraction-of-all/comment-page-1/#comment-140 doolin Fri, 18 Apr 2008 22:03:18 +0000 http://tinobox.com/wordpress/?p=118#comment-140 It's FreeMind, which I otherwise really like. I didn't want to rag on it because I really get a lot of use out of it and complaining feels unseemly! Java... heh... I could go on and on... but I won't. It’s FreeMind, which I otherwise really like. I didn’t want to rag on it because I really get a lot of use out of it and complaining feels unseemly! Java… heh… I could go on and on… but I won’t.

]]> By: Jean-Philippe Daigle http://tinobox.com/wordpress/stuff-to-do-while-compiling/waiting-on-ill-behaved-software-is-worst-distraction-of-all/comment-page-1/#comment-139 Jean-Philippe Daigle Fri, 18 Apr 2008 21:55:46 +0000 http://tinobox.com/wordpress/?p=118#comment-139 >> “Save As…” dialog for a popular note taking application written in Java takes quite of time to load, like more than a minute. AHA! You don't mention what note taking application this is (I don't know of many particularly popular java desktop apps - jEdit, maybe?), but this probably isn't the app's fault, it's rather a Java/Swing problem I've seen occur over here with our own apps. Your application is probably opening a JFileChooser, and on some systems (I haven't been able to reproduce this issue on my own box, despite trying to replicate the necessary conditions), when a JFileChooser is first loaded, there's a HUGE spike in activity from the javaw.exe process. In fact, when one coworker complained that the "Open..." dialog was coming up very slowly, I ran filemon (great tool from Sysinternals, now Microsoft) and filtered for file operations made by javaw.exe. The result surprised me: the javaw process was reading and going through each and every .zip and .jar file on the Desktop (and this user had many). Unfortunately, I didn't have enough time on my coworker's machine to investigate further (I would love to get to the bottom of this), but we deleted all the zip files stored in his Desktop and My Documents folders, and the JFileChooser dialogs instantly started loading up much faster. >> “Save As…” dialog for a popular note taking application written in Java takes quite of time to load, like more than a minute.

AHA! You don’t mention what note taking application this is (I don’t know of many particularly popular java desktop apps – jEdit, maybe?), but this probably isn’t the app’s fault, it’s rather a Java/Swing problem I’ve seen occur over here with our own apps.

Your application is probably opening a JFileChooser, and on some systems (I haven’t been able to reproduce this issue on my own box, despite trying to replicate the necessary conditions), when a JFileChooser is first loaded, there’s a HUGE spike in activity from the javaw.exe process. In fact, when one coworker complained that the “Open…” dialog was coming up very slowly, I ran filemon (great tool from Sysinternals, now Microsoft) and filtered for file operations made by javaw.exe. The result surprised me: the javaw process was reading and going through each and every .zip and .jar file on the Desktop (and this user had many).

Unfortunately, I didn’t have enough time on my coworker’s machine to investigate further (I would love to get to the bottom of this), but we deleted all the zip files stored in his Desktop and My Documents folders, and the JFileChooser dialogs instantly started loading up much faster.

]]>