I used can plugin (source plugin, can be cansimplugin) and canplay utility( from can-utils) to send ~1000 can frames / changes of the VehicleSpeed per second.

On Jun 24, 2014 10:22 PM, "Rees, Kevron" <kevron.m.rees@intel.com> wrote:
On Tue, Jun 24, 2014 at 11:21 AM, Rees, Kevron <kevron.m.rees@intel.com> wrote:
> On Tue, Jun 24, 2014 at 10:11 AM, Marek Timko <marek.timko1@gmail.com> wrote:
>> Hi,
>>
>> I checked the latest code and I see 2 issues that can cause a crash.
>> Both related to DBus signaler.
>> 1. You have to protect queue with mutex,
>> because timer may be called from different thread than thread in which you
>> are inserting into queue.
>
> Right now it all happens in the same thread.  When would it not be in
> the same thread?
>
>> 2. AbstractType::setValue does delete mValue and set the new pointer. From
>> dbus signaler you are accessing mValue. I can reproduce crash in < 50ms when
>> changing property every 1 ms.
>>
>
> Good catch.  I'll look into it.

What's the best way to reproduce it.  I've got the following config
and I'm not able to reproduce it...  It could be that my local changes
are obfuscating reproduction though...

{
        "sources" : [
                {
                        "name" : "ExampleSouce",
                        "path" :
"/usr/lib/automotive-message-broker/examplesourceplugin.so",
                        "delay" : "0"
                }
        ],
        "sinks": [
                {
                        "name" : "DBusSink",
                        "path" :
"/usr/lib/automotive-message-broker/dbussinkplugin.so",
                        "frequency" : "60"
                }

        ]
}


>
>> I did some performance improvement, but I haven't been able to compare
>> because of the crash of the original code :-)
>>
>> Marek
>>
>> On Jun 11, 2014 9:41 PM, "Marek Timko" <marek.timko1@gmail.com> wrote:
>>>
>>> Just came to my mind: I have a very good experience with Intel VTune  ;-)
>>> It was on Windows, but it's available also for Linux.
>>>
>>> https://software.intel.com/en-us/intel-vtune-amplifier-xe
>>>
>>> It's able to to show CPU usage per function.
>>>
>>> Marek
>>>
>>> On Tue, Jun 10, 2014 at 12:47 AM, marek.timko1@gmail.com
>>> <marek.timko1@gmail.com> wrote:
>>> >
>>> > Hi Kevron,
>>> > I see that there is still 8-9% CPU usage in performance
>>> > test(https://bugs.tizen.org/jira/browse/TIVI-2623).
>>>
>>> I haven't pushed some of the more impactful changes to tizen yet.  So
>>> the most recent test doesn't include those (0.11.809 vs 810).
>>>
>>> > I suggest to use valgrind with callgrind plugin(--tool=callgrind).
>>> > QtCreator has a nice support plugin for valgrind.
>>> > You can find tho most often called methods(and time consumption) and
>>> > improove the most critical then.
>>> >
>>>
>>> Agreed.  I do use that tool in QtCreator.  It's very nice.  There's a
>>> lot of data to sift through.  So far I've only been addressing the
>>> biggest pigs I can find, which are typically related to DBus usage.
>>> But as that becomes less of an issue, I'll have to use the tools to
>>> find smaller "pigs".
>>>
>>> > And I still think that you should replace all method calls with
>>> > arguments
>>> > passed by value with arguments passed by (const) reference. At least
>>> > those
>>> > under lib folder - it affect all plugins and can be called very often.
>>> > For example AbstractRoutingEngine::setProperty(AsyncSetPropertyRequest
>>> > request) is called for every signal change, If I remember correctly.
>>> > It also should reduce CPU usage. ( Imagine std::string -> there is
>>> > always at
>>> > least one malloc, one memcopy and one free call for each method call
>>> > with
>>> > arguments passed by value for each std::string argument).
>>> >
>>>
>>> Agreed.  Passing by const ref makes sense.
>>>
>>> > Marek.
>>> >
>>> > Sent from my mobile
>>> >
>>> > _______________________________________________
>>> > AMB mailing list
>>> > AMB@lists.01.org
>>> > https://lists.01.org/mailman/listinfo/amb
>>> >