View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003536||3 - Current Dev List||Maintenance||public||2019-11-01 10:27||2019-11-01 10:27|
|Target Version||Fixed in Version|
|Summary||0003536: Rig Control radio definition structures lead to cumbersome program structure|
The Rig Control application is largely driven by huge (!) structures in the RadioOptions.cpp these statically-initialized tables of data are keyed by radio and radio model, and offer command strings and some parameters for each command a radio might implement. The product supports more than 130 radios, and even simple radios have 20 to 30 commands. More interesting radios have more than 100 commands; there are many different tables grouped functionally, so the file is huge and cumbersome. The RadioOptions file is more than 23000 lines in length which, by any standard, is unacceptably long. The file size even causes tools to break; diffs in the Azure DevOps UI are impossible since the file is so long.
The tables are heterogeneous. Different radios live side-by-side, and not all commands or vendors implement things the same way. One command in a given table might need a two-digit hexadecimal number, while the very next command in the same table might use a four-digit decimal number as a parameter. Instead of putting the code and data in the same structure, functions in the CRadioOptions class attempt to handle each exception case, often varying common behaviour based on radio manufacturer and model.
The data is un-ordered. To find a command for a certain radio, the whole table is searched linearly. Hundreds of linear searches happen each second over these tables, since the Rig Control application pounds the radio interface without throttling (See Mantis 3535). As a result, CPU usage is very high and performance of the Rig Control application is affected. Large if/else trees and switch statements try to do the right thing, but the data and code are so far apart that any changes are cumbersome, and adding conditional code to fix one parameter for one radio ends up making the quagmire even thicker.
The structures use strings to identify radio manufacturers and models. The strings are redundantly stored with each command (rather than grouping commands of a single radio model into a structure), so memory usage is quite inefficient. Given the linear searches described above, Rig Control is performing hundreds of thousands -- probably millions -- of string comparison operations each second it's connected to a radio.
I've had some success splitting tables off into organized maps. (see RadioOptionsSliders.cpp, RadioOptionsToolTips.cpp, and so on ...) This effort should be refined and continued. A good way to start would be to identify candidates for refactoring and open tracking issues in Mantis for them. Once all the refactoring of the data tables is done, code can be refactored so that each entry in the table represents an functional object that actually implements the command, rather than passive data that supports some other code which implements the command.
This ends up being an incremental rewrite of the Rig Control engine, but I think it's importance can't be denied. The code right now is barely maintainable design mistakes are showing through to the product's implementation an usability.
In order to approach the completion of the rewrite, the team will have to be willing to accept that the fix might make things worse before they get better. Since the company owns very few radios to sue for testing, and promises to support such a wide variety of radios, it might be that a rewrite is unrealistic. This mostly leaves us stuck with the poor decisions, though some incremental progress might still be possible.
|Tags||No tags attached.|