 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2005Performance on today's desktop
With today's *average* personal/business desktop computing power, do you consider Java based client applications to be slow? (to remain pure, let's just concentrate on Swing based apps) If so, at what point (in time and/or JVM release) did this performance issue become a non-issue? If not, is it the application architecture or the JVM (and its libs, i.e., Swing) that's behind this lag in performance? Please base you reply on desktop computers that can be purchased in your market today, clean of all the infestations of unnecessary memory resident and background processes that are normally pre-installed on commodity type Win systems. That was very bad! Please _revise_ question to: With today's personal/business desktop computing power, do you consider the performance of Java based client applications to be satisfactory? (to remain pure, let's just concentrate on Swing based apps) If so, at what point (in time and/or JVM release) did this performance issue become a non-issue? If not, is it the application architecture or the JVM that's behind this lag in performance? Please base you reply on desktop computers that can be purchased today, clean of all the infestations of unnecessary memory resident and background processes that are normally pre-installed on commodity type Win systems. Sorry for the confustion.. > With today's *average* personal/business desktop computing power, do > you consider Java based client applications to be slow? (to remain > pure, let's just concentrate on Swing based apps) They're not blazingly fast, but they're not slow. I guess it depends on what you mean by slow. Slower than native? User would say that it's slow? > If so, at what point (in time and/or JVM release) did this > performance issue become a non-issue? I think it had less to do with the JVM than with improvements in hardware over tmie. > If not, is it the application architecture or the JVM (and its libs, > i.e., Swing) that's behind this lag in performance? [quoted text clipped - 3 lines] > memory resident and background processes that are normally > pre-installed on commodity type Win systems. Why? That's not a realistic expectation of a user machine. User machines were probably purchased a few years ago and are almost certainly infested.  Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html > With today's *average* personal/business desktop computing power, do you > consider Java based client applications to be slow? (to remain pure, [quoted text clipped - 5 lines] > If not, is it the application architecture or the JVM (and its libs, > i.e., Swing) that's behind this lag in performance? I've been using the IntelliJ IDEA Java development environment, a Swing app, for about two years and it's fine on average to high end PCs. At first it seemed a little slower than native GUI applications, but definitely useable. I never had any problem with it's speed. Since about a year ago, the difference has not been noticable; there's been no "lag". > Please base you reply on desktop computers that can be purchased in your > market today, clean of all the infestations of unnecessary memory > resident and background processes that are normally pre-installed on > commodity type Win systems. Most computers I work with are loaded with lots of background processes. Actually, one of the guys has noticed that it doesn't play well with the Novell Groupwise client for Windows, come to think of it. But I never noticed that problem. In general, my sense is that with today's machines, and improvements to Java, Swing application performance is acceptible. You could easily try it out for yourself by trying some of the apps found here: http://java.sun.com/products/jfc/tsc/sightings/ E > With today's *average* personal/business desktop computing power, do you > consider Java based client applications to be slow? (to remain pure, > let's just concentrate on Swing based apps) The two Java applications I think of when I think of "Slow Java Applications" are Eclipse and JEdit, and occasionally Azureus. The only native program that I know of that does something of similar complexity to Azureus is eMule, and they're about the same speed. That is to say, the bottleneck is probably not CPU power but rather disk I/O and network I/O. The only native program that I know of that does something of similar complexity to Eclipse is Visual Studio. Actually, Visual Studio does far less "real time code analysis" (e.g. detecting errors as you type, quickfixes, intellisense, etc.) The two are of comparable speed, with Eclipse being a bit faster while actually "running" (might be an illusion from it continuously pre-compiling, as opposed to VS's "compile when the user says to compiler"), but Eclipse takes longer to load and quit. The only native program that I know of that does something of similar complexity to JEdit is TextPad. TextPad does quite a deal less than JEdit, but TextPad is blazing fast compared to JEdit. So here's a situation where Java might actually lose out due to performance; whether a user prefers JEdit or TextPad would depend on whether they are willing to wait longer in exchange for more features or not. Maybe someone should optimize JEdit (be sure to profile first!), or write a clone of TextPad in Java, with all the extra features in JEdit stripped out for performance? For every other Java application I've used, speed was not an issue. As a specific example, JDiskReport (http://www.jgoodies.com/freeware/index.html) shows you free disk space on your harddrive. The equivalent native program is DiskSpacePlus (http://www.softwhile.com/product_dsp.html). I find JDiskReport actually "feels" faster, but this probably due to JDiskReport using a seperate thread to scan the disk drive than the one drawing the UI, while the DiskSpacePlus application seems to be using the same thread for both (i.e. while scanning the disk, it does not repaint the window or responds to mouse clicks). So, IMHO, Java is "fast enough" except in the domain of plain text editors. > If so, at what point (in time and/or JVM release) did this performance > issue become a non-issue? Maybe I was a late adopter, but I've never encountered a Java program that was slow for which there existed a noticeably faster native program (except for the JEdit vs TextPad situation mentioned above). I'm told there was a point in history during which Java was dog slow. I guess back then, people didn't bother releasing many Java applications because it was so slow, which is why I never really encountered any such applications. When Java sped up, more applications were released which were written in Java, and so when I encountered them, I never experienced this "slowness" that some people claim to be a property of Java. > Please base you reply on desktop computers that can be purchased in your > market today, clean of all the infestations of unnecessary memory resident > and background processes that are normally pre-installed on commodity type > Win systems. I'm basinc my reply on my own experiences, which is composed mostly of my own personal computer. - Oliver >>With today's *average* personal/business desktop computing power, do you >>consider Java based client applications to be slow? (to remain pure, >>let's just concentrate on Swing based apps) > > The two Java applications I think of when I think of "Slow Java > Applications" are Eclipse and JEdit, and occasionally Azureus. Eclipse is not a Swing app. JEdit is incredibly badly written and is slow because of its "optimisations" (what else would you expect from a GPL program</troll>). When I think slow application, I think Thunderbird, Firebird, Opera and gedit. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >When I think slow application, I think Thunderbird, Firebird, Opera and >gedit. Why are browsers slow? 1. because servers are slow 2. because transmission is slow 3. because of errors causing retransmissions? 4. because of having to parse unclean markup and make sense of it anyway. 5. because HTML is so designed that you need the entire document before you can completely nail down the layout. 6. something else. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. I'm wandering into the middle of this, but... > Why are browsers slow? > [quoted text clipped - 6 lines] > before you can completely nail down the layout. > 6. something else. It varies. 1, 2, and 5 are common. I'd never dream of 3 or 4 making any difference at all. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >>When I think slow application, I think Thunderbird, Firebird, Opera and I mean Firefox (sorry Borland)^^^^^^^^ >>gedit. > > Why are browsers slow? > > 1. because servers are slow Rarely. > 2. because transmission is slow I don't need to use my 33.6 kbps modem anymore, since digital has become available across this densely populated country. > 3. because of errors causing retransmissions? Hope not. > 4. because of having to parse unclean markup and make sense of it > anyway. I don't think that's really a problem, although it can't help with maintenance. > 5. because HTML is so designed that you need the entire document > before you can completely nail down the layout. That hasn't really been a problem since 1997. Kind of related is overly long HTML. I believe display times tend to dominate, but pages with loads of stuff going on appear to be a bit slow. http://bugs.sun.com/bugdatabase/index.jsp as an example. Sites using JavaScript to animate are just evil (particularly if you have a large number of tabs open). > 6. something else. Mostly it's down to the GUI responsiveness. I used Firefox briefly after Mozilla until Opera came to my rescue (which isn't half as bad). Firefox is truly amazing. Open a new page and it locks up for a while. Any operation and goes into vegetive mode for a while. Back on Mozilla I once timed opening the history window taking one and three quarter minutes. For Opera the RSS reader is really irritating. Okay, some of the irritation is feeds that don't actually include the article inline. Take ages to move from one article to the next. Above 140 ms (or thereabouts) response time user interfaces become disconcerting. For long pages, which have their visible portions displayed perfectly accurately it inhibits progress by giving a busy cursor. Everything is in fact ready to go, but Opera is putting up stop signs. Also the usability of the search impacts on actual performance. I haven't noticed any incremental search, so finding keywords becomes an arduous task. It could do better switching between tabs isn't particularly clever. Okay, updating the page may take some time, but that's no excuse not to update the tabs. And they swap massively, but what doesn't. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > I'm told there > was a point in history during which Java was dog slow. I think that's true. When I started programming in Java in 2000 I tried to use Sun's "Forte" IDE which was written in Java. On a 550 mHz PC with 256 MB or RAM it was indeed miserably slow. > I never experienced this "slowness" that > some people claim to be a property of Java. I can think of reasons someone would choose not to develop a desktop app in Java. However, the slowness issue has been pretty much resolved. It's too bad the Java platform can't shake the reputation of being slow, even though it isn't anymore. E > Maybe I was a late adopter, but I've never encountered a Java program > that was slow for which there existed a noticeably faster native program > (except for the JEdit vs TextPad situation mentioned above). You bring up great examples, and I totally agree with them. But, let's look at similar examples from the other side. What about office type applications (Word, Excel, Power Point)? Only one I can think of is ThinkFree (not sure if they include an API to integrate with their product). Perhaps there is only one choice of a decent HTML or PDF renderer in the market, and the price is way up! Very few Email and SQL clients (dbVisualizer rocks!). Hardly a fully functional reporting tool that would meet Crystal Reports or MS Access' reporting features plus ease/speed of report design, and the list goes on... I do believe the speed has been a non-issue, even with Swing, for 2 to 3 years now but don't understand why desktop Apps (free or for $) are very rare, specially the kind that can integrate and enrich other Java desktop Apps. >I do believe the speed has been a non-issue, even with Swing, for 2 to 3 >years now but don't understand why desktop Apps (free or for $) are very >rare, specially the kind that can integrate and enrich other Java >desktop Apps. Same reason you don't see non-java such apps. To compete you have a lot of catching up to do. The other reason is Java is very easy to decompile. Companies like to keep they code obscure. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > Same reason you don't see non-java such apps. To compete you have a > lot of catching up to do. The other reason is Java is very easy to > decompile. Companies like to keep they code obscure. OpenOffice is gaining quite a momentum worldwide, even here in the U.S. where MS has every government branch in hand. The state of Massachusetts is dumping MS Office in favor of OpenOffice due to its support for OASIS' OpenDocument as its default format (XML, but the right way!); and that's an Open Source software, whether the free version or the commercial one (StarOffice). Last I heard, Novell is also working on porting Evolution to Windows – Yet another “in your face” competition to Microsoft, and again, open-source (at least partially, not sure of its release 2). JetBrains (IntelliJ), Borland, Sun, Oracle, IBM and many others have done well selling Java based commerical software despite the risk of decompilation. They're threatened by free software, not open source. > > Same reason you don't see non-java such apps. To compete you have a > > lot of catching up to do. The other reason is Java is very easy to [quoted text clipped - 6 lines] > right way!); and that's an Open Source software, whether the free > version or the commercial one (StarOffice). Java is not a perfect fit for the desktop, which means that developers have to do more legwork to generate an application that 'fits in' than they would if they used the platform native tools. I find that additional work is not all that rough, usually, but if it is not done, then the app stands out as a turkey. It is the failure to do that final fit and finish pass that makes most Java application kinda bite. Those that have had that done seem to work pretty well. (I speak both of the commercial ones, and the custom apps that our group writes.) One good litmus test for whether the company 'gets it' is whether they produce a Mac version. A linux version is also a decent predictor, but the platform is close enough to Windows in look that it is not as clear. While engineering their Mac release, they usually find a lot of 'well how does Windows do it' problems, that then get addressed early in the product life cycle. OpenOffice has made the classic mistake - waiting until their app is mostly done before considering a Mac build. Thus, any problems will be found too late in the development cycle for them to consider fixing. NetBeans, on the other hand, has done a fairly good job of looking at what it will take to make their IDE Mac-like. They still have a ways to go, but they are making appropriate changes. IDEA has been doing this for a while, and is correspondingly far ahead on that score. Producing a Mac version will not insure good quality at the other end, but it will mean that you question your platform specific assumptions early in the process, and figure out your growth path. Scott SignatureScott Ellsworth scott@alodar.nospam.com Java and database consulting for the life sciences >>>Same reason you don't see non-java such apps. To compete you have a >>>lot of catching up to do. The other reason is Java is very easy to [quoted text clipped - 12 lines] > additional work is not all that rough, usually, but if it is not done, > then the app stands out as a turkey. Personally, I don't subscribe to the “fit in” notion as long as the App behaves in a generally accepted manner (UI). However, I would admit that I'd be a lot happier if my App does “fit in” without doing any platform specific coding, nor relying on third party libraries for that (IOW, JRE's responsibility). However, the question I wish to ask is that how many end users (home or business) out there make their software purchase decision based on the “fit in” criteria? I'm confident that if Adobe were to offer their Photoshop or even PDF viewer in, say Java/Swing straight up (it's a hypothesis), they would still be the market leader of such product segment, and that's due to the overall quality and value of their product. In the case of Mac, Apple would benefit greatly if Java desktop Apps would boom, just like they're benefiting from free Unix/Linux based software out there. IBM is constantly knocking on developers' doors to market Java solutions on IBM high end servers; perhaps Apple has better plans. >>>> Same reason you don't see non-java such apps. To compete you have a >>>> lot of catching up to do. The other reason is Java is very easy to [quoted text clipped - 31 lines] > market Java solutions on IBM high end servers; perhaps Apple has better > plans. apple never gave a sh.t for java, and they still do not. anyone using os9 could see that , long before osx was released, 1.1.8 was the de-facto standard on apples os9 for 2 years , whilst everyone else was on 2.x same on osx now. with this built in java crap, we lag by several major revisions. I'm working with apple now on a bug that stops you printing ANY documents from java , if you send more than 1 document. it is reproducible only on osx and on all JVMS including 1.5. They fixed it on their high-end machines,(>900mhz) but not on the "low end stuff" and it's now been over 3 months. ( its being "verified", same as my other bugs in their java implementation, being verified for over 2 years" (sounds like sun)) not to mention their shitty implementation of the java tool box. When printing documents using: PrintServiceAttributeSet printServiceAttributeSet = new HashPrintServiceAttributeSet(); // aset.add(MediaSizeName.ISO_A4); //does not work crashes or hides printers // aset.add(new Copies(numberOfCopies)); does not work does not EVEN have the code implemented for setting number of copies page size etc. despite it being in the 1.4.x spec. yes i still have to loop to print multiple copies, and hope my printer has the correct size stock. Apples answer is "duplicate bug- previously reported", no sh.t , you mean i'm not the only person trying to print documents. Even me telling you this means i can be butt f.cked under their non-disclosure agreement. Steve > apple never gave a sh.t for java, and they still do not. > anyone using os9 could see that , long before osx was released, 1.1.8 was the > de-facto standard on apples os9 for 2 years , whilst everyone else was on 2.x > same on osx now. with this built in java crap, we lag by several major > revisions. I beg to differ. I have met the people involved, and they do care. They do not, however, have unlimited resources, and the resources they get are based on what the developer community and sales force demands. There was not sufficient call for an OS 9 1.2 VM to justify the rather amazing amount of work, given that OS X was their future. Had they failed to move to X, they would have ceased to exist. Outsiders could do a Java port, were they interested, but from what I have heard, Sun does not give a damn about the platform, and it is not clear whether Apache's project is going to produce a working JVM. Scott SignatureScott Ellsworth scott@alodar.nospam.com Java and database consulting for the life sciences >> apple never gave a sh.t for java, and they still do not. >> anyone using os9 could see that , long before osx was released, 1.1.8 was [quoted text clipped - 18 lines] > > Scott We are not talking about resources to develop some mickey mouse project needed by 50 people, we are talking about making sure the basics work. you consider printing is not basic enough? how about correct language support? > >> apple never gave a sh.t for java, and they still do not. > >> anyone using os9 could see that , long before osx was released, 1.1.8 was [quoted text clipped - 19 lines] > We are not talking about resources to develop some mickey mouse project > needed by 50 people, we are talking about making sure the basics work. I am not pretending that their implementation is perfect. I am saying that 'Apple does not give a sh.t for Java' is in direct opposition to a team of over a dozen people paid to write it, with two new hires recently, and an open job req. The team is bigger than the Core Data group was through most of Tiger development, IIRC. Heck, the shared archive feature of Apple's 1.4 VM got moved into Sun's 1.5 implementation, so they are doing real and original work. This is money being spent, and thus Apple clearly does care. The test of whether the 'basics work' is the JCK. You cannot ship if you fail to pass, so if something is missing, bug Sun to add it to the JCK. As far as my earlier argument about missing Mac libraries on the Java side, let me rephrase. Apple's resources are not unlimited, and thus they have to be allocated. If you want an API to have a Java implementation, you have to convince Apple that it is worth spending the time and treasure. That convincing comes through the developer community and through what sales reports to them. I find sales awfully powerful in that discussion, given that the java team is funded from the same $129 OS sales that drive Cocoa and the core OS. > you consider printing is not basic enough? Apparently Sun did not, as it did not make the JCK. I just read your earlier post again, and the release notes. Given that they did fix some printing bugs, they obviously tested printing. Given that your bug is still there, they did not test it well enough. I would be surprised if your bug was a known one on ship day, as it did not make the release notes. > how about correct language support? Correct language support? If, by this and 'we lag by several major revisions', you meant that we have 1.5_02 when 1.5_05 just shipped, well, they do have a preview of 1.5_04 out now. Or would you rather they held back for another few weeks to ship _05? (I, personally, wanted _04, so I could get the NetBeans folks to bring up their profiler now.) Sun could always ship a VM for the Mac, but we saw how that worked last time. Maybe the Apache group will succeed at making a better VM than Apple, but again, I am not so sure that will work. Scott SignatureScott Ellsworth scott@alodar.nospam.com Java and database consulting for the life sciences Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.