• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Faster Developer Throughput with OMW and related tools

XEWANNABE

Member
Can anyone discuss the hardware they've used to accelerate the development process on OW/Xe? I noticed that several computer vendors are touting Itanium 64-bit Intel systems with 1.x GHZ processors. This raised several questions for me:
1) Do OMW and related tasks get faster with faster cpu? more memory?
2) what is the optimum developer station?
3) Will the JDE/OW thick-client product run the Intel 64-bit platform with Windows/2000? or only XP?
4) Risks and rewards of trying to get more OMW power?

Any thoughts?

Currently on IBM Thinkpad 600E
w/ 500MB memory and 4-500MHZ processor

One World/Xe B7333/15.1
AS/400 Enterprise Server
Citrix
 

jgersic

Reputable Poster
From what I understand of the Intel Itanium processor, running a 32-bit
application on it will not run any quicker, if not slower. The Itanium
processor uses a different set of microcode, and native applications
really have to rewritten to take advantage of the processor..
As far as OMW performance, what are you talking about specifically? If
you are talking about compiling performance, then a quick processor and
decent memory is important. I can't see a big disk drive like a fibre
array is really going to help much in OMW/compiling performance. I would
go towards memory and a quick processor. We use a dual Pentium 3/xeon
and get a client/server build completed around 7 hours when performed on
the deployment server..These are only my experiences, other may have
completely different opinions..

John


Xe, Update 2/SP16, oneoffs: SP16_011, SP16_016
NT/SQL7, WTS/Citrix Metaframe 1.8






Xe, Update2, SP16
NT/SP6a, SQL7/SP3, WTS/Metaframe 1.8
 

Zoltan_Gyimesi

Legendary Poster
XEWANNABE,

When do you feel Development slow under OMW?
1.) Opening the Designer Tools
2.) Closing the Designer Tools (e.g. Saving in the Tools)
3.) Check Out/Get, Check In, Save
4.) Working in the Designer Tool
5.) Working in OMW (e.g. Add Project; Add/Remove Owner, Object; Listing; Finding; etc.)
6.) Building Business Functions
7.) Any other

FYI: I have a 300MHZ Intel CELERON cpu, 256 MB RAM (128 previously) and decent HDD space and I am satisfied with the performance. Recently after my memory extension (128 to 256) I experienced extra performance improvement after I ran a SpeedDisk program which eliminated the file defragmentation and optimized the file locations on the HDD.

Thats all for now,

Zoltán



B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
 

XEWANNABE

Member
Speed issues arise when initially starting OMW but more when:

opening any of the designer tools from OMW
working in the FDA tool and "compiling" (the more forms in an application, the longer the save takes?)
searching for BSFN, SYSFUNC, DD Items

Sure, OMW init, check-in/checkout could be faster, but I'm really thinking of the stuff you do all the time when developing. Event rule manipulation, FDA open/close, application save, system function selection.

I was looking for someone who has determined the "killer configuration" needed for running the One World/Xe developer tools.


One World/Xe B7333/15.1
AS/400 Enterprise Server
Citrix
 

Zoltan_Gyimesi

Legendary Poster
Hi XEWANNABE,

Excuse me that I come back with questions only but maybe your answers could be useful for us to explore what is the real problem. Let's see.

1.) What about the performance running "normal" OW applications (e.g. Address Book) on the same configuration where OMW is slow?
2.) What about the performance on an other HW (mainly CPU) on the same LAN connector?
3.) What about the performance on the slow HW connecting it to the LAN on other points?
4.) Have you checked the performance in the Task Manager (e.g. which task use mostly the CPU when OMW is slow; Do you fit into the physical memory or the system works already in the virtual memory)?
5.) What about after running a SpeedDisk? Have you checked the free disk space and file dfragmentations?
6.) When were the indicies rebuild?
7.) Isn't any Data Source volume filled and auto-incrementing?
8.) Would be usefull some typical bench-mark for us with all information making possible for us to check the performance on our system for performance comparison.

The performance problem could have severa cause as, CPU, disk fragmentation, running in virtual memory (much memory not enough when something "eat" the most part of it), LAN problem (physical, protocol, settings, etc.), missing or corrupted indicies, filled data source volumes, running concurrent tasks with high priority), and many more.

Hope, the Forum will be able to resolve your performance issue.

Regards,
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
 

David Robertson

Reputable Poster
Re: RE: Faster Developer Throughput with OMW and related tools

Hi John,

Run on a fairly decent modern computer (an Intel "Celery", really Zoltan!), with as much memory as you can wedge into it (256Mb+). Dual/multi processors doesn't help much for the development workstation.

Run Win NT 4.0 service pack latest (6b?), not Win 2000. This is just my experience, but I find the development tools much more stable under NT 4 (B7332 sp16.1). Lots of virtual memory seems to help, at least double your RAM.

Lots! of hard disk space. I like to be able to take local backups of my pathcode, and have several environments, and still have at least have 1 Gb free.

Make sure you have a 100Mb or better LAN connection. Make sure your connection to the deployment server is optimal. This is the biggest bottle neck.

Otherwise, I personally haven't to many complaint about the performance of tools as such. Only for the massive APPL's, check-in and out can take a while, but this is really a bandwidth problem. I've never noticed how long FDA takes to come up, even for the big APPL's, so from that you can I assume I think it's "acceptable". I have noticed big APPL's take a while to save and exit, while it's validating event rules. Not a problem, but faster would be better if you were doing a lot of work in mega-APPL's.

Cheers,
Dave
 
Top