Adding memory profiling page.#236
Conversation
ralph-lange
left a comment
There was a problem hiding this comment.
Very nice report! It's a bit long in my opinion, but there are some redundancies which can be removed to shorten it. I marked them in my comments.
| docs: | ||
| - concepts/benchmarking | ||
|
|
||
| - title: Memory profiling |
There was a problem hiding this comment.
I propose to put benchmarking and memory profiling in one menu, What about a joint menu "Analysis"?
There was a problem hiding this comment.
If the analysis is only about the client library and does not cover the middleware, it could even be put into the existing Client Library menu.
There was a problem hiding this comment.
It covers the middleware and the RMW, so I'd say it doesn't properly belong to the Client Library section. On the other hand, I like the idea of putting it together with the benchmarking. However, we decided to remove the section and subsection structure, and leave only a few independent sections, same as in the Overview part. Do we want to go through with it or do we prefer to group topics under common sections as it is right now?
|
|
||
| The measurements are conducted on a micro-ROS Client application with a varying number of entities: either publishers/subscribers (1, 5, 10, 15) or client/server (1, 2, 5, 10). | ||
|
|
||
| All the tested apps run on top of FreeRTOS and inside of an ESP32 board. The board is connected by either UDP or serial transport to a micro-ROS Agent running on a Linux machine. As explained above, the choice of FreeRTOS has been by virtue of its memory management functionalities, which easily allow to compute the memory used by applications. |
There was a problem hiding this comment.
Probably the ESP32 can then be omitted in the abstract.
There was a problem hiding this comment.
I think it's normal to repeat something that is already said in the Abstract, so I'd leave that. But I definitely took away its previous occurrence.
No description provided.