Performance: Block Variables Breakdown

In response to my previous blog, Chris Nokleberg noted that if we're using String#equals a lot, interning will have an additional benefit...namely because String#equals short-circuits if both String objects are ==. I had forgotten about that benefit, so I thought I'd poke around for places it might have an effect.

In digging a little, I was reminded that DynamicVariableSet, which holds block-local variables, does a linear search for retrievals and mutations. Compare that to method-local variables in Scope, for which all clients must pass an index to get or set a value. I'm not sure if there's a reason why DynVars must be retrieved by name and Scope vars can be directly indexed...it's probably historical from the C code or a limitation of the current parser. In any case, a linear search could theoretically represent a performance issue accessing or modifying block-local variables. So I thought I'd run some numbers to see how frequently we have to search past the 0 value in the DynVarSet. Here's the breakdown while gem installing rake:

Count of block var retrieves from indicies 0 through 6:
516436
226049
42687
1170
656
122
1

So a total of 787121 block variable lookups, with percentages below:

index 0: 65.6%
index 1: 28.7%
index 2: 5.4%
...with the remainder filling out the last 0.3% of accesses

What can we learn from this? Well DynVarSet currently allocates initial space for up to 8 variables, based on someone's long-past examination of code that showed a maximum of 6 was a good estimate. The numbers above show that, for RubyGems + RDoc at least, a maximum of 3 would cover 99.7% of all cases without requiring expansion of the array, and that with a subsequent expansion to 6 slots we would cover all but 0.0000127% of cases. So using 6 as a maximum and always allocating 8 slots is perhaps a bit generous. More profiling on more code is warranted here, but it might be safe to drop the initial size to 3 and leave in the doubling when expanding.

It also shows us that we pay the cost of two String#equals calls for 28.7% of lookups, and pay for three in 5.4% of lookups, with higher counts statistically insignificant. So although it might seem like we're unlikely to suffer much of a performance hit because most block var lookups are at index 0, our cost to lookup or modify block variables is doubled in over a quarter of cases and tripled in a twentieth of cases. If we normalize all lookups to the same cost (X * 99.7 versus X * 139.2), that translates to a 28% performance boost for block variable lookup cost. Note that I'm not measuring block variable modifications here either, which would conceivably see a similar boost.

And of course what it doesn't show (but which we know to be true) is that if we were able to eliminate both the linear search and the call to String#equals, we'd save a very large percentage of block var lookup time, since we'd reduce it to a simple array indexing. I think it's worth exploring how we could do that--especially since we already do it for Scope in all the same places.

Isn't optimizing legacy code fun?

Performance: Inlining Strings

A while ago, we decided to inline all appropriate symbolic strings as they entered the AST. This appeared to help performance a measurable amount, presumably for two reasons:

1. The AST would take up less space in the long term
2. Since Strings cache their hashcodes, having each identical string in the AST be the same object would reduce the number of hash calculations.

And the numbers seem to bear it out. Here's a local rake install:

Without interning AST strings:
real 1m19.894s
user 1m18.649s
sys 0m0.920s

With interning AST strings:
real 1m15.021s
user 1m13.785s
sys 0m0.948s

So it's very measurable...in this case 4-5 seconds out of 80 seconds, or about a 6% gain with interning.

However this week I realized the fallacy of the second point above. In order to intern each incoming string, Java must hash them. This causes all strings entering the AST to be hashed once anyway in order to get the interned version. In fact, it could reduce performance, since we're now forced to hash strings we might never encounter during execution.

I can't confirm that this is 100% true, but it's a reasonable theory. String.intern() is native code, but logic dictates that the fastest way to intern strings would be to use an internal hash/symbol table. So I proceeded this evening to try removing interning to see how it affected performance. I hoped to get a small gain during execution due to a large gain during parsing. The numbers above show that I lose a measurable amount overall by interning. However, I do see substantial parse performance gains:

With interning AST strings (Time.now - t method of measuring 100 parses):
11.101

Without interning AST strings:
9.404

About 1.7 seconds out of 11, or a whopping 15% gain in parse speed without interning. AARGH.

At this point I'm leaning toward removing interning and swallowing the 6% performance hit temporarily until we can figure out where it's coming from. Logically, interning everything should only add overhead, or so my brain tells me. Where's the flaw in my logic?

My London Schedule

So here's the times and places. I want to get together JRubyists to just chat a bit at some point, and it seems like Thursday or Friday would work best. The only concrete suggestion so far is the Fitzroy Tavern on the 15th, around 6:30PM-7:00PM (thanks Damian). This works for me, and it's after the conference. Here's a goofy Google Map to Fitzroy from the conference center.

I'm also planning to attend the "Pizza on Rails" event on the 13th, so folks can find me there.

I'll keep this entry updated as things come in, so it can be used for reference.

13 September, 6:00AM: Arrival in London (Heathrow)

Other than getting checked into the hotel, I have that whole day free. I don't plan to cram for my presentation or anything, since it's not until Friday (and I don't really work that way). To avoid the lag I'll probably sleep as much as I can on the plane. Getting out and about once I get there ought to get the circadians whipped into shape.

13 September, 6:00PM: Pizza on Rails

Pizza on Rails is around 6PM, with pizza at 7PM.

14 September, 9:00AM: RailsConf Day One

The "Welcome" is at 9, and it goes straight through until 8:30PM with a lunch break from 12:30PM to 2:00PM and a dinner break from 5:50PM to 7:30PM. I'll probably try to grab meals with folks from the conf.

15 September, 9:30AM: RailsConf Day Two

Lunch break is the same as Day One, and the conf is scheduled to go through until 6PM, with "Closing Remarks" coming after that. Probably be out by 6:30, and the Fitzroy is pretty close. Maybe someone not going to the conf can get there early to scope it out.

15 September, 3:00PM: JRuby on Rails

I'm in the last set of speakers, before the final plenary session with James Duncan Davidson and Dave Thomas. I'm up against cleaning up rails, adding unicode to rails, and project management for rails. I wish I could attend the unicode session, but I'll try to grab Dominic offline.

15 September, 6:30PM: JRuby Meetup

So far I think we'll just be at Fitzroy Tavern, as mentioned at the top of this post. All are welcome...I don't fly out until 1:25PM the next day, so I can stick around for a while.

16 September 10:00AM: Departure

Given the recent TERROR scare, I'm going to be extra careful and head to the airport nice and early. I'm not particularly worried about TERROR, but I am over-cautious about giving security enough time to scour my person for soda pop and lip balm.

Thus ends my first trip to London. It's too bad it will be so short, but I have business to attend to stateside immediately after the conference. Hopefully I'll stop back in when I'm in the EU for JavaPolis.

I hope to see plenty of JRubyists in London!

IronPython Demo for John Udell

Tim Bray tossed me a link to an IronPython screencast given by Jim Hugunin for Jon Udell.

On the surface, it does look fairly impressive. However I'm not impressed for the reasons some folks might be. So here's the notes I took while watching this demonstration...take them for what they're worth.

IronPython with Avalon demo

Here Jim demonstrates instantiating and manipulating a small Avalon UI in an interactive python session. This is essentially the same as the demonstration I gave at JavaOne using IRB to script Swing components (and no, I'm not claiming to be the first to do such a demo). It shows that Avalon produces very impressive and beautiful UIs, and the XAML under the covers is pretty big and ugly. It also shows that IronPython has some nice integrations with .NET code. Beyond that, I wasn't any more impressed than I was when I got the IRB stuff working. It's cool, to be sure, but it's not new.

Notes:

• Tab completion is nice, but in an interactive shell it isn't very exciting. IRB already does this in Ruby (not in JRuby unless you have a ReadLine library wired in), and completion against running code is easy.
• Importing a whole namespace from .NET is really, really nice. We would love to be able to efficiently support the same, but there's currently no capability in Java to get all classes or subpackages in a package. That's the reason why you have to include each class you want. You can include a whole package with JRuby, but for each package you include we have to brute-force search them for all Java classes from then on. O(n) to locate a class, where n = number of packages imported. It sucks. Including the classes directly has no unreasonable overhead, though.
  
• It looks like IronPython has a few nice wrappers around the delegate-based events in .NET. That's the b.Click += some_handler...some_handler is python code that becomes a delegate instance; the += adds it to the Click event. Nice and simple. Everyone feels differently about events+delegates versus listener interfaces, however, and in Java we've got the latter. We'll need a different way to make things nice and simple.
  
• Most of the UI interaction stuff we can already do with JRuby, though it's not wrappered quite as much; you're basically just calling Swing methods directly. We could add a lot here by making something smart that handles common UI use cases for you. This demo somewhat reminds me of the Groovy demo at JavaOne 2006, where the presenter used OLE automation to work with an Excel document. It was a great OLE demo. It was a pretty good Excel automation demo. However it was only a mildly entertaining Groovy demo because it just called OLE methods like any other language could. The Avalon stuff in this demo is similar.
• Almost all the functionality shown, including XAML manipulation, etc, is .NET code, not IronPython code. Ignore anything about XAML and Avalon to see what's really interesting...the various little ways IronPython makes .NET components available to python. Again, an impressive Avalon or XAML or .NET demo...but only a pretty nice IronPython demo. But pretty nice is pretty good. IronPython looks pretty nice so far.
  

Visual Studio demo

VS 2005+ is very nice, but I think most folks already knew that. However the python support looks much better than I expected, on par with what RDT has built for Ruby in Eclipse, though maybe a bit more polished.

Notes:

• It was a bit of a dodge that he didn't admit how Jython compares performance-wise to IronPython. Of course, Jython has been around longer, and I'd wager that it's faster. I've made it perfectly clear that Ruby is still faster than JRuby, because I don't think distracting folks from JRuby's performance issues will make them any less of a concern. It's too slow. We'll fix it.
  
• I've given a lot of thought to where we'd need to hook into JRuby to be able to online debug code, and it won't be terribly difficult to do. We also might be able to simply get Ruby's normal debugging hooks working with a little effort, and just use those remotely. Either way integration into the IDE is just icing on the cake.
• I completely disagree with the long-standing idea that programs should be implemented in Python or Ruby (or some other dynlang) and then migrated toward C# or Java (or some other static lang). I application code should *stay* Python or Ruby, because much of the value of those languages is in the long-term maintenance of the code you write. The minute you port that code to C# or Java (or C) you've lost that benefit. You've set it in stone, as far as I'm concerned. Is any application code ever to a point where you want to set it in stone? Wouldn't we rather just code in dynlang all the time?
  
• I didn't see any code completion or refactoring of python in Visual Studio, unfortunately. There was a little C# completion only, which is well-known and deserving of praise. That's a big area Ruby IDEs could jump ahead. The editing capabilities for python are also only touched on briefly, since he presents a pre-written python script and then writes and calls some C# code.
• The online debugging in Visual Studio looks really nice...I want that for Ruby. The JRuby compiler I've been working on will include .rb filenames and line numbers in the eventual stack trace from the compiled code, so eventually you'll be able to step through Ruby code using my compiler...even after it's compiled to Java class files:

  at MyCompiledScript.fib_java (samples/test_fib_compiler.rb:2)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  

PowerShell

I read a bit about the PowerShell stuff the other day and I don't really have much to say here. It's basically a set of .NET objects that are interactively available to dynamic .NET languages for interacting with the system...a nice set of OO components to provide what UNIX command-line utilities do on UNIX, in a sense. It's neat and all, but it's not relevant to IronPython except that you can script those components in python.

Other notes

Using import clr in IronPython is a clever way to add in .NET decoration of python types; we could probably add that, so that Ruby strings automatically have Java String methods.

Conclusion

My opinions are sour grapes, perhaps...but I could do almost all of the non-IDE stuff in a screencast of my own. The IDE stuff will come soon. It's still a very nice demo, and kudos to Jim for what IronPython has become. I'm impressed.

I think it's safe to say that we're behind IronPython on having a fast, well-integrated implementation (a detriment of the legacy code from the original port) but way ahead on completeness and compatibility with C Ruby (a benefit of the legacy code from the original port). The IDE stuff is not yet as nice for us, even counting the Eclipse-based RDT. NetBeans and Eclipse are in many ways not as nice as Visual Studio, so there's some additional catchup to do there.

I'd like to know how folks out there feel about our approach to JRuby, working to make it a drop-in replacement for C Ruby so it can take advantage of all the libraries and applications out there. As far as I know, neither Jython nor IronPython can actually run most of the major Python applications, and certainly nothing as complicated as Rails. Our choice has made some things harder, but I think the value of making Ruby work on the JVM would be greatly diluted if you couldn't run real Ruby apps.

FWIW, I've had a long-standing task to do a nice screencast like this for JRuby using Swing and other libraries, and I dir a very similar UI demo for JavaOne. Hopefully soon I'll have time to do a longer, fancier one.

From Eclipse to NetBeans: Part 2

I had planned to post a "Part 1.5" that summarized all the emailed and commented help I got for my first post, but I've been too busy working on JRuby on Rails to try most of those suggestions out. Several folks offered a whole bundle of useful tips that will address many of the "bad" points in Part 1. I will revisit those as I have time, and hopefully use them to compile a "NetBeans for Eclipse Users Walkthrough. For now, however, I continue to muddle through with NetBeans as-is.

NetBeans continues to surprise me in both good and bad ways. Some features seem to be very nice and very well thought out, while others...well I wonder if anyone's actually using them, because they're very cumbersome. Most of the UI seems to be solid and clean under Java 6, but there are some occasional jarring glitches and (in my opinion) poorly-designed interfaces. Sometimes NetBeans seems to know exactly what I want to do...sometimes it seems to make what I want to do as hard as possible. It's still been worlds better than earlier versions, but I'd have expected a level of polish I'm just not seeing yet. Is it because I'm running a beta IDE on a beta JVM? Perhaps. Perhaps not.

However I'm going to be a trooper about this and do what I can to fight through issues. I think NetBeans really has a lot of promise if these things can be ironed out, and truth be told, most stuff works fine. However the stuff that doesn't work...REALLY doesn't work.

And again, please don't consider this an attack on the NetBeans product or team. NetBeans is very impressive...but there's room for a lot of good improvement. I hope this hard look at NetBeans vs Eclipse will help make progress to that end.

The Bad:

1. "Extract Method" should have an option to replace all instances of identical code with calls to the new method. I use that feature in Eclipse *very* frequently.
2. No "Inline Method" refactoring? I really need that one. Here's a typical use case for me:
   • N methods all have the same code, for whatever reason..perhaps I've refactored and simplified them each down to the same chunk of code.
   • Extract Method to create a new method that does that duplicate block, and replace all instances of duplicate code so all the old methods call the new one.
   • Inline all the old methods so all callers now call the single new method. The old methods are eliminated.
   In this way, I manage to make all callers calling duplicative methods call a single new method without ever manually modifying a single line of code. I have many such refactoring tricks I have learned over the years, many of which depend on being able to inline methods and extract methods globally. JRuby would not be where it is today without those refactorings.
   
3. The "Find Usages" dialog has a grand total of two or three checkboxes (depending on visibility), one of which I will probably rarely use (find in comments) and the other which should probably just be on by default (find overrides). I would much prefer to just go straight to the search results, rather than always have to hit "Next" on this dialog.
4. There's no way to look at the project view and know whether I have errors in my project or not, even after running a build. In Eclipse, if I save a class with errors, the entire project and all directories leading to that class get marked with a big red X. In NetBeans I can see if the current file has errors, which is good...but being able to see errors anywhere in the project is a must when I'm making refactoring changes that can affect more than one file. I need to know at a glance if I've broken something else. For larger projects, re-running the build can be prohibitively slow.
5. My Projects and Files views only show the little "versioning cylinder" icon next to SOME of the items in my project. Even more confounding, in the Projects view, only SOME packages show up as versioned. I haven't figured out a pattern to it.
6. I should be able to change the delay between typing code and having NetBeans re-parse it and display error squiggles. By my estimate, it takes about three seconds for it to realize I've typed bad code, by which time I've almost certainly moved on to the next line or a different file completely. Yes, it checks when I save, but checking as I type *very slowly* is not really useful. EDIT: I did find this setting...it's at 2000ms by default. I've set it to 1000ms, so we'll see if it's disruptive. Is it set so long because it causes a lot of overhead?
7. There are surprisingly few "non-advanced" settings and a baffling array of "advanced" settings. Almost everything I need to do is in the "advanced" section. Perhaps I could just turn on an "always advanced" view and save myself that button-press?
8. Why can I right-click items in the Advanced Settings tree, to bring up the exact same properties listing I see on the right-hand pane? Prefer one way to do things...the right-click properties dialog should go.
   
9. I can't find how to change the default L&F. Maybe it's in the Advanced Settings somewhere, but I couldn't locate it. Metal is an OK L&F, but it's jarring when the rest of my system looks completely different. It also seems too "bright" to me, for some reason...I prefer softer earth tones.
10. Code completion brings up two popups: one for the list of methods, and one for documentation on the selected method. One displays itself above the line I'm typing and one displays below the line. This effectively hides all contextual code around the line I'm typing, which is frustrating. The documentation window is also enormous, and usually mostly empty.
    
11. There doesn't appear to be a way to revert changes when the changes are new files. Modified files get reverted, but not files or directories that are new. Oddly enough, they DO show up as changes when choosing "Show Changes".
12. I selected all new items in the "Show Changes" pane and hit the delete key...BEEP, nothing happens. I right clicked and selected Delete...and it appeared to proceed with the delete operation. The Delete key should map to a logical Delete operation whenever possible.
13. After deleting, the view continued to show new files that were no longer visible in the Files view, and refreshing did not help.
14. After manually cleaning out the new files, my NetBeans project appeared to be totally hosed, returning a goofy error about a parameter field not being normalized (filed as bug 83665). I had to completely wipe out my working copy and re-get it...
15. ...only to find that once I had deleted my project, NetBeans totally forgot my SVN URL and I had to retype it. Thankfully it remembered my credentials, but why didn't my old URL show up in the list of possible URLs anymore?
16. Then it again asked me where I wanted to check things out, defaulting to my home dir. Can't I just set a single work location and be done with it?

At this point I figured I should call it a night.

The Good:

1. NetBeans shuts down WAY faster than Eclipse. That's a huge benefit. I don't know what the hell Eclipse is doing that takes as much as 15 seconds to shut down, even if it was sitting idle.
   
2. NetBeans ships with way more capabilities than stock Eclipse. I found the Module Manager today to turn some stuff off and was absolutely stunned to see how much stuff comes in the base install. However there's a bad side to this too: NetBeans could be perceived as having a slower startup time because of all these modules, even though most folks will never use most of them. Maybe have a few coarse-grained use cases people can choose to enable AFTER installing and starting up the first time. At any rate, I'm impressed with what ships out-of-the-box.
3. I can confirm that antialiasing appears to work for the whole IDE under Java 6, as reported by one commenter. Very nice!
4. I like being able to turn on line numbers for all editors in one place. However, others may want to be more picky.
5. NetBeans seems to be much more deterministic than Eclipse. For example, when Eclipse is under heavy load, occasionally mouse clicks and keypresses will disappear into the ether. When Eclipse gets laggy I frequently have to double-check that the code or shortcut I just typed was actually received. This sometimes leads to me typing only half of a line of text or typing a search query into my editor. NetBeans so far does not seem to "lose" UI events like Eclipse does.
6. I see that right-clicking editor tabs DOES allow me access to Subversion. I just don't have it in the main pane's context menu. That's totally acceptable, so mark another item off the bad list from Part 1.

Subversion...Wherefore Art Thou

The subversion issues have been severe enough I figured I should rant a bit before closing this article out. As far as I can tell, SVN support is simply broken in 5.5b2, to the point that I'm now afraid to perform many operations out of fear that they'll nuke my working copy in some heinous way. In this case, I had no local changes to lose (or to struggle to save), but I could picture some painful corruption like the "parameter field" error coming right in the middle of some multi-file refactoring. I pray that doesn't happen.

Painful to live in fear, isn't it?

Jack-of-all-Trades...but...

NetBeans seems to have a vast range of capabilities, rivaling multiple major Eclipse-related projects all rolled into one. However there's a lot to be said for polishing the core pieces to death before launching into a new set of features. Subversion should just work. The UI should just work, without glitches. Professional-grade refactorings should work like you expect them to (and Eclipse's complement of refactorings is actually overshadowed by some other IDEs, so NB is well behind the curve here). Under no circumstances should a working copy be so badly damaged by an operation that it must be flushed out and re-gotten. And so on...

These key features need to work perfectly, all the time, before anyone will consider launching into more advanced features like Java EE support or Database Browsing. If I can't even do basic SCM operations on my project, why would I ever invest time in anything more than simple Java code editing?

That said, I think NetBeans could really shine like a star with some polishing...polishing that may be coming in NB6, I really don't know. Most of these issues are obvious or minor, and many of them are in newer features that have perhaps not been tested as well as one would like. Hopefully the excellent improvements in NetBeans over the past year will draw more users...and more testers...to the project.

RailConf Europe 2006 - I Will Be There!

It's official! Travel arrangements are currently being made for me to attend and present at RailsConf Europe 2006 in London!

I had not expected to make it, so this comes as a bit of a surprise. I guess I need to put together some sort of presentation now, don't I? Oh, and make sure I'm happy enough with JRuby's Rails support to be comfortable...

I'll take comments on this off-the-top-of-my-head agenda:

• Who Am I
• What is JRuby (dime tour, nothing too deep)
• Why Rails on JRuby (probably a few slides on JDBC, alt persistence layers, EJB integration, legacy code integration, why JRuby is better in some ways than Ruby)
• Why not Java-based web framework X
• Demos
• What doesn't work
• What's next, future plans, how can you help
• Q/A

I'm also hoping the JRubyist Mongrelites are able to get things working before then. I'll probably try to help them, wrap up enough bugs so that most walkthroughs in AWDwR work nicely, and create the presentation over the next two weeks.

I hope to see you in London!

P.S. If anyone wants to give me any pointers on travel from the US to the UK, please do. I'll be travelling alone and I've never been across the pond. Thankfully, I already have my passport, but other than that I'll be flying blind. If any Brits feel like taking me under their wing once I arrive (or just grabbing a pint or two), that would also be much appreciated. I plan to arrive during the evening of the 13th, flying back the morning of the 16th.

From Eclipse to NetBeans, Part 1

I am attempting to make the switch from Eclipse to NetBeans, and this is a raw dump of the pros and cons so far during that process. Note that these are not meant to question design decisions behind various NetBeans features; they are simply differences that have made the conversion harder or easier.

Stats

Opteron 150 w/ 2G memory
Ubuntu Linux 6, AMD64
Java 5, x86_64 version
NetBeans 5.5b2

The Bad

I'll start off with the bad, because these are more obvious. It's much harder to list good things, since the "best" features will be those that are intuitive to an Eclipse user and that require no re-learning. Please keep in mind that I'm a rank newbie when it comes to NetBeans, but I'm a pretty solid developer. In other words, if I have trouble with these things, most new users will too. There will be more to come, and I'm willing to discuss these with any of the core NetBeans folks at length.

The list, in the order in which I encountered them this evening:

1. Why isn't antialiasing turned on by default, and why is it a bit hard to find? I don't think of this as an editor setting...I want antialiasing on everywhere. To be honest, I don't understand why this is even a setting. Why would I choose the "make everything uglier" option?
   
2. SVN should be available in the default install. Perhaps I'm biased because I need it, but I really, really loathe having to install additional plugins whenever I set up a new workspace.
3. The concept of multiple workspaces with their own plugins and settings is VERY attractive. NetBeans seems to lack this concept.
   
4. I have always preferred to keep the concepts of repository management and project sources separate, rather than making a hard link in my IDE between the two. NetBeans appears to require me to go through a lot of anguish each time I want to switch a project from trunk to branch or back.
   
5. Also, there has developed in the Subversion world a standard of using top-level "trunk", "branches", "tags" dirs, and at least one SVN plugin for Eclipse uses that convention to make switching branches, merging, and updating more intuitive. NetBeans should do the same, allowing the typical branch/tag operations against this de-facto standard layout.
   
6. I tried to delete a CVS-based project to re-checkout via SVN, and it didn't appear to delete all the files successfully. I had to do it manually AND go back through the Subversion wizard again.
7. I hate wizards. Don't make me go through a wizard for every one or two settings when I could easily enter them all at once. Wizards like this are totally unhelpful.
   
8. Some time back, Eclipse made the wise decision to also show all non-source files in the source or "package" view. It was widely considered a very good idea, and I miss it. I'd like to have a single view that has source or "Project" smarts without masking files and dirs I really want to see.
9. Eclipse recently added a full-text search to their settings dialog that works very well for finding the location of hard-to-reach settings. I would have found two NetBeans settings much more quickly with such a search by entering "antialias" and "browser".
10. Browser selection should prefer the settings of the host platform (I'm on Ubuntu Linux).
    
11. NetBeans is a goofy name for an IDE. When I think NetBeans I think "beans for doing network stuff". Forte and Eclipse are better names, though completely undescriptive. Something along the lines of "UberIDE" would be even better. Names like Visual Studio, JBuilder, IDEA, and so on have far less ambiguity about what they mean. NetBeans seems misleading, and I doubt anyone would guess it's an IDE if asked.
12. Eclipse keybindings should include C-A-t (open a specific class) and C-A-r (open a specific file/resource anywhere in the project)
13. Eclipse provides options for sorting the Outline or "Members View" of a class by name or by visibility, which is nice.
14. Eclipse provides options to show packages in a hierarchy rather than as expanded names, which is very nice when expanded package names take up a lot of space (as in JRuby). There are also features to allow using a hierarchy but still collapsing empty packages, so I could have org.jruby as a top-level node (because the org package is empty) and then source files and subpackages under it.
15. Editors are anti-aliased, but nothing else is. Why?
16. Eclipse supports collapsing multiline /* */ comments, which is very nice for us since every JRuby file includes a reasonably long licensing block at the top.
17. Eclipse uses color, bolding, and italics better to differentiate different kinds of variables, methods, keywords, and type names.I would rather see type names, static variables and methods, constants, and fields offset in text than method calls and names. It appears that NetBeans by default only offsets the following:
    • Comments: grey (I think green is better/easier to read, but that's a matter of opinion)
    • Method names, both declarations and calls: bold black
    • Keywords: blue
    Perhaps accessibility plays a decision in the more drab and colorblind-friendly defaults?
18. Idle/startup memory use seems a lot higher in NetBeans. Mine's idling at 399MB, where Eclipse hovered under 200MB most of the time with several other projects checked out.
    
19. FIXME-style task tags in comments are really, really nice, and I know a LOT of projects that use them (basically, EVERY project that uses Eclipse)
20. I would like to be able to manually clear search results from previous searches to eliminate text highlighting.
21. Being able to right click within the file and have SCM actions available in that menu is extremely nice, so I can go to an editor for a file I know I want to commit or compare and do that action right away.
22. Many files in my project do not have a Subversion submenu in any view...they have a CVS view, and it wants to try to add or delete them from CVS. This isn't even a CVS project, so I have no idea why the CVS submenu would EVER be appropriate to show up. As it is, a large number of files show the CVS submenu and can't be committed directly; I have to commit at a higher level. This is a major goofy bug, perhaps in the Subversion module.
23. NetBeans takes longer than Eclipse to start up.
    

The Good

It's only fair to sugar the salt a bit, since it's so far been a pretty good migration. NetBeans has come a long way in the past year or two, and I'm very impressed.

1. I'm absolutely stunned at how responsive the UI is most of the time. I frequently have to double-check that an operation has finished successfully because they happen so fast. Sluggish response was one of my biggest reasons for not using NetBeans in the early days.
2. I appreciate the fact that NB uses the ant script for builds. I think this is "The Right Way", though I have my doubts about Ant as the "Right Tool" for building software in general. Seamless maven2 integration might be a good thing to add.
   
3. The Runtime pane is nicer and includes more useful things than stock Eclipse provides.
4. The default monospaced editor font is much neater and more compact than most Courier fonts, which is what Eclipse uses by default. I dislike serifed fonts for code, even more than I dislike non-monospaced fonts.
5. Automatically updating the UI based on outside changes to the project's files and dirs is a no-brainer; I hate having to refresh in Eclipse.
6. Undoing all changes to an unsaved modified file causes it to be marked as unmodified again; this is a Very Good Thing.