Prototype performance testing suggested that rather then send the class through JMS, it's must easier to use a JMS StreamMessage, and simply write the fields to the stream. Of course, given that, the object becomes overhead. For example, upon receiving such a message, I read the fields from the JMS StreamMessage's stream, create a new Order object, and pass the Order object to another object, which parses out the fields into a different container object. So basically I created a class just to pass one value instead of 5 in a method call, and then destroyed the object. Seems wasteful.
Why then, have I not gotten rid of the Order object? Well, it's apssed 2-3 times on the client, and another 2-3 times on the server. If I can have a single object being passed, instead of each primiative, that makes maintanece easier, so that I only need to update the one object's construtor (and get compile exceptions if I'm not careful), rather then trying to update multiple method calls. In the latter case, if I miss one, I could get some non-intuitive runtime errors.
My question is, given that this class is created, fields are set, it's passed, fields are read, and it's destroyed, are there JITs which will recognize this and optimize away the class, saving my the overhead of its contruction? In that case, I'll keep using it. Otherwise, maybe I'll use it up until the end of development, and then carefully remove it by hand, and hope that in the future we make few, careful changes to what needs to be included as part of an order.
Based on the output it looks like HotSpot in JDK 1.4 for Windows does not optimize the class away - but perhaps other JVMs do.
One issue that occurs to me is that if client-side performance is an issue, you probably can't guarantee what JVM implementation they're using anyway. So even if some JVMs do perform this optimization, you can't assume it will happen. However this scenario is probably unlikely, as the server-side performance seems more likely to be the issue. (Unless individual clients are really active.)
Note that if client-side performance is not a bottleneck, that suggests that your final code could keep using the message objects on the client side, even after you've rewritten the server code to bypass using them. That might reduce the maintenance prolems a little, as 2-3 client classes can continue to use the same interface. You just have to customize 2-3 server classes - or less, if the bottleneck only applies to 1 or 2 classes.
Hope that is of some use. BTW, sorry you didn't get any feedback on your last Performance post. I looked at it, but didn't really have anything to add but "build a mockup and see" - which was kind of obvious after all, and evidently what you did.
[ December 16, 2002: Message edited by: Jim Yingst ]
As a sidenote, this is one project where I probably can fix the JVM. most of us, myself included, used to writing software which will be used by IT depts or other developers--people who knw what a JVM is. The people running the client software withh be business school students--people who think when it comes to databases, "Mauve has the most RAM" ;-) So we can actually tell them what to do, or simply install a particular JVM with the app (which we probably need to do anyway in many cases), and just have them use that.
Thanks for noting that you looked at my last post. I wasn't sure if people just ignored it toally (although I know that this forum tends to be skipped over by most JavaRanch users), or just didn't have any suggestions, or maybe blew it off b/c of the grammatical typo in the topic :-) (which apparnetly can't be edited).
maybe blew it off b/c of the grammatical typo in the topic :-) (which apparnetly can't be edited)
No, that sort of thing normally would give me an extra incentive to post, just to tease you about the typo. (Hey, you said "apparnetly "!) BTW you actually can edit the topic, by editing the first post in the thread.
Originally posted by Ilja Preuss:
Mark, are you sure there is no behaviour that in fact would belong to that class?
Pretty sure, it's nothing but gets and sets. Are you asking from a domain standpoint? We have the concepts of markets and portfolios, which slice and dice orders; but the order itself is fairly inert.
Originally posted by Ilja Preuss:
BTW, instead of removing the class, it would probably be easier (and more maintainable) to use an object pool - when instantiation *really* becomes the bootleneck (which I'd tend to doubt...)
Yeah, I thought of this, but it seemed like more toruble then it's worth. I don't feel like writing one for the client where performance probably isn't the issue. As Jim noted, it's the server about which I'm concerned, but because I'm using EJBs, I have to rely on the server to do the object pooling. but that means I need to have different objects on the client and server, because one needs to be an EJB. Too much hassle!
Thanks for all the feedback.