Very high CPU usage when continously calling GetMessages with a lot of data.

[projix]

Hello,

My code is basically:

Code: Select all

while (true) {
   GetMessageResults results = Channel.GetMessages(1, timeout);
   // Do stuff with result here...
}

When processing many messages the CPU usage is very high using your DLL. It hits 100% on one core.
I am using ISO15765-4.

If I use any of my other devices then there is no such issue with the same amount of data. Of course those devices do 15765 flow control in hardware...
Seems like the blocking on this call is somehow handled inefficiently? Or there is some other problem in the SW implementation.
I can not see inside the DLL with my profiler, so I can not give you any more information.

[K.Wagner]

Hello,

If I use any of my other devices then there is no such issue with the same amount of data

I assume you are not using the same code for reading from the other hardware, right?

Of course those devices do 15765 flow control in hardware...

Thought this makes a difference, a continuously read process may still cause a CPU load problem, even if the communication protocol is implemented in the hardware.

If you have a dedicated thread for reading and you use a statement like yours, then it is normal to reach a 100% CPU load. I assume, the other hardware are working with different applications (different code). For instance, when using .NET (C#, VB.Net, C++/CLR), CPU processor time is managed different, so that maximal load of CPU is automatically avoided to keep performance in the app.

To sum up, we cannot discard a problem in an API, but a call like yours in a thread does end with such a CPU load, if "any" task is made in there without giving processor time to other tasks. Try using a Sleep(1) for each iteration in the while statement.

[projix]

You assume wrong.

I use exactly the same code with all my hardware. User can freely select J2534 device in dropdown before beginning communication.
I have 4 J2534 devices and only your device exhibits the problem and only when there is a lot of data received.

Is that more clear?

There is zero reason to put any hacks like Sleep(1) into my code, because timeout in my case is CanMax or CanEnhMax and the operation is supposed to block until data is received.
In fact, all the CPU time is taken up by the api call going into your library!

I quote from the J2534 API:

Timeout
Timeout interval(in milliseconds) to wait for read completion. A value of zero instructs the API/DLL to
read buffered receive messages and return immediately. A nonzero timeout value instructs the API/DLL
to return after the timeout interval has expired. The API/DLL will not wait the entire timeout
interval if an error occurs or the specified number of messages have been read.

I am really disappointed by your response, blaming it on user code. Make a simple benchmark and you will see the problem.

I did not check if your API actually breaks the spec by returning earlier with 0 messages (thus causing much more calls than normally), but it either breaks the spec by returning early instead of blocking or the processing inside is very inefficient.
I do not have the source code for your DLL so I can not see with a profiler where the problem is. It is your job to do.

A 3rd party 15765-4 implementation with your device does not have this high CPU usage problem. Maybe that should ring some alarm bells.

[PEAK-Support]

Nobody blame on anyboddy - so stay cool - contact our support with the company name you work for, and we will forward it to our developers.
Keep in mind that x-thousends of customers, and many tool developers, use exact this code - and do not have this probllem - think about it!

[K.Wagner]

Hello,

first of all, in any moment was my intention to blame code from anyone. We have several APIs that works different and in most cases a call in a while (true) leads to such behaviors. I admit, I missed the timeout in the function call i.e. mixed it with other issue that I was investigating, kind of things happens, sorry about that. This is nevertheless not a reason to get rude. Pointing this out again would be enough before telling me what is my job here.

As I said in my last comment we are not discarting the problem is from our side, I just made a suggestion for a test. We are in process of releasing a new version of the library, where different problems were fixed. The new version should be available for download today or tomorrow. It is recommendable to check if this version fixes your issue.

[PEAK-Support]

thx Keneth - so i will close it here!