patterncsharpMinor
End User defined Controls and calculations on WinForm. Thoughts on speed?
Viewed 0 times
winformcontrolsusercalculationsendandspeeddefinedthoughts
Problem
Users can define custom controls that are added to an entry form at run-time. The values of these controls are later stored in a MySQL database. Optionally, users can define 'recipes' to auto calculate some controls.
For an example, a user could enter Gross and Tare weight and use a FieldCalc for the Net Weight. In this case the ValueChanged event of both Gross and Tare will call FieldCalcValueChanged below.
Multiple recipes could be triggered by a change to a single field. There is no loop protection/detection.
CalcTotal does the work, processing each line of the recipe, then assigning the outputs. This could cascade other recipes.
In general, the above example is the normal case. In a few cases, there are 3-6 mileage fields, which total to a single field.
The code works great. But slowly. So much so, is some cases, that users choose to disable the FieldCalc recipes, and run a 10-key, which is not acceptable.
Any suggestions for speed or otherwise are appreciated.
configfieldcalc:
configfieldcalcstep:
```
id configfieldcalcid step linetype output operator valuetype option notes
---- ----------------- ---- -------- --------------------------------------------- ------------------------ --------- --------------------------------------------- ---------------------------------------------
2 2 1 math weightnet math_assign metric weightgross
3 2 2
For an example, a user could enter Gross and Tare weight and use a FieldCalc for the Net Weight. In this case the ValueChanged event of both Gross and Tare will call FieldCalcValueChanged below.
Multiple recipes could be triggered by a change to a single field. There is no loop protection/detection.
CalcTotal does the work, processing each line of the recipe, then assigning the outputs. This could cascade other recipes.
In general, the above example is the normal case. In a few cases, there are 3-6 mileage fields, which total to a single field.
The code works great. But slowly. So much so, is some cases, that users choose to disable the FieldCalc recipes, and run a 10-key, which is not acceptable.
Any suggestions for speed or otherwise are appreciated.
configfieldcalc:
id fieldcalcname code
---- --------------------------------------------- ----
2 NetWeight
6 MilesDifference
5 NetScale
7 MilesCalcconfigfieldcalcstep:
```
id configfieldcalcid step linetype output operator valuetype option notes
---- ----------------- ---- -------- --------------------------------------------- ------------------------ --------- --------------------------------------------- ---------------------------------------------
2 2 1 math weightnet math_assign metric weightgross
3 2 2
Solution
Hook up a profiler and measure what exactly is causing the slow down. Everything else is basically stabbing in the dark. That being said, there are a few things you could check:
-
You have a few loops in there checking
The first option is cheap and will reduce some of the code complexity (
-
You have a few loops in there checking
_metricControls and _timeControls frequently for one with a specific name. Store them in a dictionary keyed of the name rather than as the plain IEnumerables:public FieldCalc(IEnumerable metricControls, IEnumerable timeControls)
{
_metricControls = metricControls.ToDictionary(c => c.Name, c => c);
_timeControls = timeControls.ToDictionary(c => c.Name, c => c);
}- You do a fair amount of parsing so you could look at caching it. Caching can speed up things but comes with it's own draw backs so I'd be checking first if it's a problem or not.
The first option is cheap and will reduce some of the code complexity (
_metricControls[op.Name] as opposed to a multi-line LINQ statement) so I'd do it anyway.Code Snippets
public FieldCalc(IEnumerable<ITicketRateMetric> metricControls, IEnumerable<Time> timeControls)
{
_metricControls = metricControls.ToDictionary(c => c.Name, c => c);
_timeControls = timeControls.ToDictionary(c => c.Name, c => c);
}Context
StackExchange Code Review Q#18090, answer score: 2
Revisions (0)
No revisions yet.