Prerequisites 01) Windows 2000, Windows ME, Windows 98, or Windows NT 4.0 with Service Pack 6a or higher. 02)Microsoft(R) Internet Explorer 5.5 or higher 03)TCP/IP installed and configured 04) A mouse or an alternative pointing device 05)Pentium(R) II processor or higher recommended SVGA (800x600) display or higher (1024 x 768 recommended) 06) 256 MB RAM minimum 07) Disk space requirements: 400 MB minimum (based on NTFS, actual disk space on FAT depends on hard [disk] drive size and partitioning)
I would highly recommend you buy all the hardware you can afford. I am currently running WSAD on Compaq EVO with a 1.5GHz processor and 1GB of RAM. It is NOT enough! (although I think the Compaq machine and the Windows 2000 'build' my company has provided me is part of the problem.) WSAD response times are pathetic (which I am sure is due to the fact it is written in Java). You need patience with this product because context menus and dialog boxes are slow to appear (learn to say to yourself: yes, I really did click the mouse button). Also, do not not even attempt to create large source files (over 1000 lines) because, if you do, WSAD has a difficult time even echoing your keystrokes back to the display as you type in the editor. If you plan to interface with an SCM like ClearCase, which I am also currently doing, this becomes even more imperative. WSAD by itself is a dog. ClearCase makes it much worse. On my team, I don't even work inside of ClearCase because it is so slow. I have created a workspace external of ClearCase (in addition to my workspace in ClearCase) and I develop there and cut and paste my changes into ClearCase. Otherwise, I would never get anything done. To give you an example, I have an EJB project with 52 entity EJBs. It typically takes 20+ minutes to generate deployment code for the entire project. If I generate deployment code for this project inside ClearCase, I start it before I go home because it is an overnight job. That said, I like WSAD, primarily for its 'look and feel'. The interface is great and it seems well-designed but IBM needs to seriously address its performance issues. In this era of GigaHertz CPUs and GigaByte memory, WSAD's performance sucks! [ April 19, 2002: Message edited by: Jay Damon ]
It's interesting that I use WSAD day-to-day (on large projects) and have never seen the performance problems you've mentioned with dialogs and context menus. I wonder what the difference is -- I'm using an IBM Thinkpad T23 that has a 1GHz processor and a Gig of RAM with Windows 2000 -- so our systems are similar in that regard. In fact, the only problems like that that I've seen are in the views (like the EJB test tool) that are really browser views -- that's because I have to say that all-in-all Internet Explorer sucks. I'm with you on the code regeneration times, though. That is certainly an issue -- and one that IBM is working hard to resolve. Kyle
And P.S. What are you doing creating a 1000-line class!???!! Refactor it! No seriously, 1000 lines is too long for a class. My rule of thumb is that methods should average 10 lines of code and that classes should average no more than 2 dozen methods. 1000 lines is 4X that average, or refactoring-bait. Kyle [ April 19, 2002: Message edited by: Kyle Brown ]
You'll note I allow that I believe the Compaq machine and the Windows 2000 'build' I am provided are part of the problem. In fact, I run WSAD on my home machine (1.0Ghz, 384MB) and achieve the same or perhaps better performance. Still, WSAD is not for the resource-weak. That much should be obvious since we are discussing it in terms of GHz CPUs and GBs of memory. My point is that you should bring all the hardware you can muster to bear on this piece of software because WSAD will use every bit of it. It is not unusual to see 99% CPU utilization for javaw.exe in the Windows Task Manager. Worse, the Application Status is often displayed as 'Not Responding' for extended periods of time. Before I learned that you must have patience, I often thought WSAD had hung. It turns out, it just doesn't come up for air when it is performing some resource-intensive task like generating EJB deployment code or an import/export. FYI, I have been told by the local IBM reps not to open multiple perspectives because they consume too many resources. My response is: What's the point of being able to do it if you can't really do it? So, as Kyle indicates, IBM is aware of the resource problems. My experience with multiple perspectives is that they are not nearly as much of a problem as some of the resource-intensive tasks cited above. Actually, Kyle, I really like the Universal Test Client. It is much more adaptable than the UTC in VAJ. I have been able to create some really great test beans since I realized I could use HTML to format the output. Also, I like the fact that it has more functionality than the UTC in VAJ. I don't normally create large source files (i.e. 1000+ lines); I found out WSAD had a problem with them quite by accident. I began by creating a test session EJB to test all the creates and finders in my entity EJBs (of which I have 52). To simplify testing, I created a single session bean with approximately a 10-line method to test each create and finder. The bigger the the test bean got, the slower the editor response time. As I indicated, sometimes I have to actually wait for WSAD to echo an input character back to me. I agree with Kyle that large classes are bad, but surely IBM does not need to enforce this via the editor. Don't get me wrong; I like WSAD. However, rather than adding a bunch of new features to the product for the 5.0 release in July, I believe the development team's time would be better spent optimizing the product. Someone needs to tell them the Steve Jobs story of how he implored his programmers to shave a second or two off of the Mac boot times and how many person lifetimes it saved when applied to the user base.
I am also having difficulties using WSAD. Previously I was using a Dell PC with P3 1GHz and 512MB of RAM and WSAD was killing my PC!!! But now I got an Acer notebook with P4 1.8GHz and 512MB of RAM and the performance seems the same although the CPU speed is different. I think the main difference is the memory. As you can see in the Task Manager, WSAD uses few hundred MB of memory. So I think adding more RAM might increase the performance of WSAD. Does anyone know how to "tune" WSAD so that it will perform better? [ April 02, 2003: Message edited by: Grayden Chua ]
Hello greyden, I found these tips on the wsad documentation. You can find some tips to tune your websphere at the path equivalent to the following on your machine: "F:\IBM\WebSphere Studio\readme\ws\tips.html". Quite useful!! regards.
Everyone is a villain in someone else's story. Especially this devious tiny ad:
SKIP - a book about connecting industrious people with elderly land owners