On 6/20/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > ..... > 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.
We are not doing all this by hand. This is a (potentially) highly distributed J2EE application. So, CORBA is out of the question. (Not that I am so eager to try CORBA either. :-) ) > 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. Well, as far as I know, our network is EXTREMELY fast. I can't quote gigabits, but I remember someone quoting a number much higher than 1 gigabit. The issue was really flexibility of the model vs. scalability of the app. Neither is going to make it or break it, but it would be nice to know the consequences of our design decisions. So, before coding all this up, I wanted to make sure we are not going down a less than performance oriented road. Few bits here and there is not a big deal. However, this design decision is replicated throughout the app, so it could become a big deal in the long run. I think, everyone pretty much answered my questions though. Thanks! Yaakov. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
