On Sun, 2005-06-19 at 19:06 -0400, Yaakov Chaikin wrote: > Leon, > > See inline. > > > Aehm... Sorry for my incompetence, but what is a VO-model? > > Value Object model, sometimes referred to as DTO (Data Transfer Object). > > > As for the question, I'd expect a null object reference to be 24 bit, which > > should be smaller than most primitives. > > That's useful info. How do you know this? I just want some way to verify this.
Well, how about actually serialize an object with a null reference and a similar object without and then compare? :-) 24 bit is the size of a pointer in java, at least what jprobe and other profiling tools show, or at least what they showed as we used them last time. But if space on wire is your problem, I'd suggest you use the externalization instead of serialization, for example, use corba inbetween your wire-ends. Corba has an advantage of actually shortening the names of methods and variables in the compilation, for example if you have 2 methods: getAllItems and getItem it would actually send and check for getA and getI. The problem with CORBA would be, that CORBA misses the concept of null, so you aren't allowed to transmit null references (better anyway, but another discussion) and have to use primitives or NullObjects. But to be true, I don't understand how "space on wire" could be a problem anyway? Do you have so much data to transmit? Maybe you should upgrade to 1 gigabit network? It would be much cheaper than spending weeks of developerstime counting bits. regards Leon > > > Other question, why don't you develop an object hierarchy, where each > > subobject in the hierarchy contains exactly the information for a particular > > screen? > > We did this for a project before this one and it was a bit of a > nightmare. With over 40 screens that display different but similar > information. Yes, I know what you are thinking: inheritance. > Unfortunately, it doesn't work as well as it sounds. We ended up some > tons and tons of VOs. Some we had to name FacilitySummaryVo, just to > differentiate it from the full blown FacilityVo. It got messy and not > very OO at all. > > We were thinking that a much cleaner model would be to model real > world objects, not screens. This way, the entire dev team can share > the same objects. Less maintenance, less CM footprint, must more > manageable. > > Thanks, > Yaakov. > > > > > Regards > > Leon > > > > > -----Ursprüngliche Nachricht----- > > > Von: Yaakov Chaikin [mailto:[EMAIL PROTECTED] > > > Gesendet: Sonntag, 19. Juni 2005 20:11 > > > An: Struts Users Mailing List > > > Betreff: Re: [OT] Serializing object with null pointers (performance?) > > > > > > Well, the point we were shooting for on this project is to go > > > away from the "per screen" Vo structure and move to > > > "domain/business model Vo structure." Primitive vs Object is > > > really a side point. Since we are not custom coding a Vo per > > > a particular screen, we don't to carry around ANY values for > > > fields we don't need for particular screen, so that's why the > > > Object vs primitive. > > > > > > Does it take the same amount of space "on the wire" to > > > serialize a null pointer as a primitive? We are not as > > > concerned for the time it takes to serialize the object as > > > for the space on the wire. > > > > > > Thanks, > > > Yaakov. > > > > > > On 6/19/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > > > I would expect the performance of serializing a null object > > > reference > > > > to be trivially different than serializing a primitive > > > value. In fact > > > > it may be slightly worse due to the overhead of writeObject(). > > > > > > > > Unless you're doing a hell of a lot of serialization and > > > profiling has > > > > shown that it's causing a performance bottleneck I wouldn't > > > touch what > > > > you have. > > > > > > > > L. > > > > > > > > Yaakov Chaikin wrote: > > > > > Hi all, > > > > > > > > > > I have the following situation. I have a Vo model that is > > > in essence > > > > > a domain/business object model. Of course, a particular screen > > > > > doesn't need the entire model to be loaded with data. So, > > > what I was > > > > > thinking is > > > > > 1) Make all class variables objects (as opposed to > > > primitives, most > > > > > are objects anyway) > > > > > 2) Make all class variables NULL, unless I need it for a > > > particular screen. > > > > > > > > > > This way, I won't have to carry data around the wire that > > > I don't need. > > > > > > > > > > The question I have is this. What performance hit, if > > > any, do I get > > > > > by passing around an object with null pointers in it? How do they > > > > > get serialized? > > > > > > > > > > Is this a good idea in general or am I just imagining > > > that passing > > > > > around null pointers saves me "THAT MUCH"? > > > > > > > > > > Thanks, > > > > > Yaakov. > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
