Marshalling/unmarshalling costs

Tomeu Vizoso tomeu at
Tue May 20 04:36:21 EDT 2008

On Tue, May 20, 2008 at 10:26 AM, Marco Pesenti Gritti
<mpgritti at> wrote:
> On Tue, May 20, 2008 at 4:12 AM, Jim Gettys <jg at> wrote:
>> First step: data to see if there is a problem.
>> If no problem; stop.
>> If problem; fix...
>> ;-).
>> DBUS, btw, does not have to be inefficient; the wire protocol is sane
>> (distinguishing it from Corba, for example).  What Python does on the
>> way to the wire is a different question.
> Tomeu collected data about this a while ago, perhaps he still have the profiles.

Uff, no idea where that could be. But data marshalling wasn't in the
top of the list of performance issues.

In the only case I think it could be causing problems is when the
preview (max 60KB) is sent across the wire. But in the cases where
that method is used, I don't know of any performance problem.

My suggestion:

1. Use the software as an actual user would do.
2. Identify areas where slow performance causes an usability problem.
3. Profile at the system level (sysprof or oprofile) and identify
which chunk of code is taking most cpu.
4. If it's python or python-called code, use lsprofcalltree to analyze
the performance behavior:
5. Fix it.



More information about the Devel mailing list