Marshalling/unmarshalling costs

[Marco Pesenti Gritti]

http://dev.laptop.org/~tomeu/datastore*.kgrind

and

https://dev.laptop.org/attachment/ticket/3979/datastore5.kgrind

Hard to say what we profiled exactly now though :)

Marco

On Tue, May 20, 2008 at 10:36 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> On Tue, May 20, 2008 at 10:26 AM, Marco Pesenti Gritti
> <mpgritti at gmail.com> wrote:
>> On Tue, May 20, 2008 at 4:12 AM, Jim Gettys <jg at laptop.org> 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:
> http://codespeak.net/pypy/dist/pypy/tool/lsprofcalltree.py
> 5. Fix it.
>
> Regards,
>
> Tomeu
>