> So today, how do you measure expensive? And with todays flamethrowers, does > it really matter?
In my mind, performance always matters, especially if there are dozens or hundreds of processes running the logic in question. This has a bearing not only in CPU consumption but also network bandwidth. Always think about the slowest component in the stream, which in this case would be the network. If you make a single request (i.e.: the example provided earlier that put all the @ logic in a single string to be displayed in one CRT statement), that gets tucked into one network packet and is dealt with all down the line as a single entity. If you make a separate request for each field, you're initiating a separate network request and generate separate packets for each of those fields. This could result in many kilobytes of information, in multiple packets, going across the network, interlaced with the individual requests from other users, to update just a few bytes on the screen. But even if you're working on a local PC, you can see the difference between doing things in one CRT versus multiple. It's a much smoother look, which is more appealing to the end user, since the cursor isn't dancing all around the screen. As to flamethrowers, faster hardware often means that little inefficiencies can add up to huge bottlenecks when given the chance. Water always seeks its own level, and computers will always find a way to exploit the slowest component. If you have more or faster CPUs cranking out information for the network to handle, everything on the network will suffer. It's conceivable that could include things totally unrelated to the U2 application or even the server in question, conceivably having enterprise-wide implications. OK - sorry for the rant. That always seems to happen when I talk about performance. Let's try again. > And with todays flamethrowers, does it really matter? YES! Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
