Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Eclipse 4diac Wiki/Development/Breaking FORTE Changes Collection"
(Created page with ";Use 64bit datatype in forte timerhandler instead of struct : As now nearly all of our systems are 32 or 64bit systems support for 64bit datatypes is available on them. This w...") |
|||
Line 10: | Line 10: | ||
:** ''TConnection:'' for the destination list | :** ''TConnection:'' for the destination list | ||
:** ''CTimerHandler:'' the sorted insert done in the timer handler could benefit from std:vector however here clearly measurements are needed | :** ''CTimerHandler:'' the sorted insert done in the timer handler could benefit from std:vector however here clearly measurements are needed | ||
+ | :** ''CStringDict:'' replacing the stringID buffer with vector could greatly reduce the code here | ||
;Change int in receiveInputEvent(int paEIID) to size_t | ;Change int in receiveInputEvent(int paEIID) to size_t |
Revision as of 04:29, 29 August 2018
- Use 64bit datatype in forte timerhandler instead of struct
- As now nearly all of our systems are 32 or 64bit systems support for 64bit datatypes is available on them. This would greatly reduce the implementation effort for the timerhandler and I assume also some performance implications.
- This could already be a target for 1.10
- Allow using STL also in core and arch
- With the improved C++ compiler support for all platforms that we currently actively use would allow us to make more use of the standard C++ libraries.
- Use std:vector in several places instead of list can reduce memory consumption and allows use of stl algorithms for searching and sorting. Potential starters are:
- CFBContainer: for fb and subapp lists, perform a sorted insert allows for quick searches
- TNameIdentifier: makes mgm commands more flexible regarding sub-app hierarchy depth
- TConnection: for the destination list
- CTimerHandler: the sorted insert done in the timer handler could benefit from std:vector however here clearly measurements are needed
- CStringDict: replacing the stringID buffer with vector could greatly reduce the code here
- Use std:vector in several places instead of list can reduce memory consumption and allows use of stl algorithms for searching and sorting. Potential starters are:
- Change int in receiveInputEvent(int paEIID) to size_t
- requires update in code generator
- Remove event-chain execution thread pointer from function block and add it as parameter to receiveInputEvent, sendOutputEvent, and sendAdapterEvent
- requires update in code generator
- Combine connection pointers
- Currently we have three pointers in the fb handling the connection lists. These pointers could be reduced to one and an static offset stored in the interface struct could be used instead
- The performance impact of this change needs to be evaluated before applying it globally
- requires update in code generator
- CDataConnection
- Get rid of data buffer and turn any into value
- Requires to remove if2internal data con and rework how a CFB and Resource handles connections from their interfaces to internal elements. For CFBs this can quite easily be done with the input with. For resources I currently don't have an idea how to do it.
- Derive CCompositeFB from CFBContainer
- This should only be done after CFBContainer utilizes std:vector for the FBlists
- This can reduce some duplicated code between both
- Where possible change geters from returning pointers to returning const references (e.g., getFBInterfaceSpec())
- Find a way to get rid of the resource mutex
- Replace Resource pointer of an FB with a pointer to a CFBContainer
- This would allow FBs to retrieve their full hierarchical name
- only possible when we get rid of resource mutex, otherwise it will have a severe performance impact as getResource would turn into a recursive function
- requires update in code generator