Marshalling asymmetry

[woodbrian77]

I've been moving away from marshalling uses where an
instance of a class is marshalled out of one program
and later marshalled in to another program. In one
case the input is from the command line and it is
needless overhead to construct an object just so it
can be marshalled. In another case the input is coming
from a config file and again I don't (at least so far)
have a need to construct an object just so it can be
marshalled out. One question I have is if others have
or are dealing with something like this?

These two files are for the second case with the config
file.

http://webEbenezer.net/misc/cmw_user_input.hh
http://webEbenezer.net/misc/cmw_user_input.cc

I'm thinking about introducing another class and
moving some of the functionality that's in there now
to that new class. Specifically I may move the ctor
that takes char*, the char* data member and the Marshal
member function. Comments on naming that class are
welcome. Getting that char* data member out of
cmw_user_input would be helpful because it would mess
up the code generation of the marshalling ctor.

To review in one case I marshall multiple command line
args in a message (as multiple function args) and the
other side receives all of that as a class instance.

And in the second case I'd be marshalling one (related)
type and receiving it as a different type.

The marshalling-out code currently looks like this:

remoteMessages.Marshal(cmwSendbuf
,request.accountNbr
,cmw_user_input(request.filename)
);

but I may change that to use the new class mentioned
above.

This is efficiency motivated. Changing from building
the object from the config file and then marshalling
it, to marshalling it straight away reduced the size
of my text segment by 2% on gcc and 1% with clang.
The gcc result seems more impressive because gcc was
already producing a smaller text segment than clang.

Tia for your comments on this asymmetry. I'm not sure
what if anything can be done automation-wise or
convention-wise to keep the two sides in sync.


Brian
Ebenezer Enterprises - John 3:16
http://webEbenezer.net

 

[woodbrian77]

Efficiency motivation resulting in a 1% to 2% reduction in binary file

I have less powerful datacenter than most companies. I do
what I can to make up for that. The program I'm talking
about in this case is my middle tier. I have 3 tiers that
make up a system and whatever I can do to improve the
middle or front tiers helps requests get to the back tier
faster. And that helps me get by with a less expensive
datacenter than a lot of companies.

Please don't swear here.

 

[woodbrian77]

These two files are for the second case with the config
file.

http://webEbenezer.net/misc/cmw_user_input.hh
http://webEbenezer.net/misc/cmw_user_input.cc

I'm probably going to make some changes to those files
so I've copied them to these files:

http://webEbenezer.net/misc/cui.hh
http://webEbenezer.net/misc/cui.cc

After a month or so I may delete these files.

 

[woodbrian77]

I have less powerful datacenter than most companies. I do
what I can to make up for that. The program I'm talking
about in this case is my middle tier. I have 3 tiers that
make up a system and whatever I can do to improve the
middle or front tiers helps requests get to the back tier
faster. And that helps me get by with a less expensive
datacenter than a lot of companies.

I should add that the software is already fairly mature
and has been reworked a number of times, so it's 1 to 2%
of that sort of binary.

I'm a little overweight. For whatever reason losing even
a few pounds is difficult. I heard about a diet where
you diet for two days a week. That sounds OK, but haven't
tried it yet. I may make it a one day a week diet. That's
even better.

 

[woodbrian77]

I should add that the software is already fairly mature
and has been reworked a number of times, so it's 1 to 2%
of that sort of binary.

I've made some progress on this now and the results are
encouraging. I split that class into two classes. The
version to be used by the back tier is still called
cmw_user_input and the new class is cui_generator.
Doing that and changing my middle tier to refer to
cui_generator further reduced the text segment size by
about 800 bytes and it's now 2 to 3% smaller than the
original version. I didn't anticipate that reduction so
it was a pleasant surprise.

I'm including cmw_user_input.hh in cui_generator.cc
in order to say:

decltype(cmw_user_input::choices) mychoices;

That might be an answer to the synchronization aspect.
cmw_user_input is a struct so don't know if that would
work if it were a class and the data member were private.

 

[Ian Collins]

I've been moving away from marshalling uses where an
instance of a class is marshalled out of one program
and later marshalled in to another program. In one
case the input is from the command line and it is
needless overhead to construct an object just so it
can be marshalled. In another case the input is coming
from a config file and again I don't (at least so far)
have a need to construct an object just so it can be
marshalled out. One question I have is if others have
or are dealing with something like this?

These two files are for the second case with the config
file.

http://webEbenezer.net/misc/cmw_user_input.hh
http://webEbenezer.net/misc/cmw_user_input.cc

Broken links don't help.

This is efficiency motivated. Changing from building
the object from the config file and then marshalling
it, to marshalling it straight away reduced the size
of my text segment by 2% on gcc and 1% with clang.
The gcc result seems more impressive because gcc was
already producing a smaller text segment than clang.

2% impressive? It's noise. A small change to an optimisation between
minor compiler releases could have more impact. Your obsession with the
text segment size is irrational.

 

[woodbrian77]

Broken links don't help.

Here's a new set of links:

The original content:
http://webEbenezer.net/misc/cui.hh
http://webEbenezer.net/misc/cui.cc

The updated content:

http://webEbenezer.net/misc/cmw_user_input.hh

http://webEbenezer.net/misc/cui_generator.hh
http://webEbenezer.net/misc/cui_generator.cc

2% impressive? It's noise. A small change to an optimisation between
minor compiler releases could have more impact. Your obsession with the
text segment size is irrational.

I think so. I rarely run across anything that substantial.
Years ago (on this executable) it wouldn't have been. but
things are different now.

 

[woodbrian77]

I'm including cmw_user_input.hh in cui_generator.cc
in order to say:

decltype(cmw_user_input::choices) mychoices;

That might be an answer to the synchronization aspect.
cmw_user_input is a struct so don't know if that would
work if it were a class and the data member were private.

http://stackoverflow.com/questions/10924217/why-is-decltype-not-allowed-on-private-member-variables

I tested if using a friend declaration works with decltype
and it did. So most likely this approach will work if the
data members are private.

 

[woodbrian77]

In testing I found a problem related to this change.
Some code had been moved for this change from a ctor
to a "Marshal" function. (Not the Marshal function
shown below but one of the Marshal functions called
by the function below.)

That function was throwing in the testing and I was
leaving some data in a marshalling buffer that was causing
problems for a subsequent request. So I added the try/
catch stuff here:


void
remote_messages_middle::Marshal :cmw::SendBuffer& buf
,::cmw::marshalling_integer const& az1
,cui_generator const& az2
)
{
buf.NoteSize();
try{
buf.Receive(msg_id_direct);
az1.Marshal(buf,false);
az2.Marshal(buf,false);
buf.FillInSize(msg_length_max);
}catch(...){
buf.PartialReset();
throw;
}
}

Any comments on that? I'm wondering about the name
PartialReset. I thought also of RollBack. There
may be other requests that have already been marshalled
into the buffer so using the word partial is meant
to indicate that those aren't going to be voided.