Notifications
Clear all
Topic starter
Hello All,
We have had unit testing discussions before, but they have been mainly about how to speed up the development/debugging process:
https://forum.centricityusers.com/forum/unit-testing-of-vef-code-functions-forms-etc/
I am working on trying to improve the speed of form load and form responsiveness when the visit is open. Some of our custom forms are several years old and we have added additional forms or features and it seems time to refactor some code.
There don't seem to be any tools to help with testing for speed and code efficiency. I can get out the stop watch on my phone and time how long it takes a chart to load, but if I make a function slightly better I don't think that change is going to be appreciable to me until we have a handful of changes.
A couple of questions for the group. Has anyone gone through their visits and refactored their code before? How did you determine your baseline and that you were making progress? Is a mel trace a good proxy for time (a smaller mel trace == a more responsive function)?
Thanks,
Brad
Posted : October 31, 2018 1:14 am
I haven't come up with a great process for this either. I did this sort of cleanup a few years ago and it did help tremendously. The MEL Trace was my best tool. It seems that Centricity writes it in chunks though, so you will see random time gaps between steps that you would think take any significant time, so you have to sort through that.
I found my biggest time saving in a few spots.
1) eliminate observations from the form view. I replaced all observations with document variables, and I didn't save observations with direct watcher expressions. You'll notice in the code when one gets evaluated, they all get evaluated.
2) be careful with mldefs and exit loops when you have your answer. Getrow() is very slow. You will see timestamp shifts at every call. If you use them extensively, I would look at doing direct SQL queries instead. It is much faster.
3) General cleanup. I had some MEL_GET_CONTENT() calls that were using contains instead of match. It made the form loop through a lot of crap that wasn't needed. Look for functions that have a lot to execute and add a lot of lines in MEL trace and see if you can find a more efficient way.
If you are not sure if a function is taking a long time to execute, comment it out of your form and import it again, and see if there is a time difference. It also helps to do the testing on a patient with a big history, it will make the time differences stand out more.
Posted : October 31, 2018 2:19 am
Topic starter
Thank you for all of the suggestions. A question on #1 since I think I might get some benefit there: For values that you do want to capture to the flowsheet when do you capture that information? Do you have a button that you depend on staff clicking to fire a function that places the document variable into the corresponding obs term? Do you fire a function in a page close handler to do the do the equivalent of the button press above when the visit is put on hold or signed? Thanks! Brad
Posted : October 31, 2018 2:58 am
Yeah that part is important. I still capture it as the document variable changes, just not directly. This method keeps it from re-evaluating if another observation changes.
{fn SaveObs(){
cond
case getnargs() == 3
obsnow(getarg(1),getarg(2),getarg(3))
case getnargs() == 2
obsnow(getarg(1),getarg(2))
case getnargs() == 1
return obsnow(getarg(1))
endcond
return ""
}
}
{saveObs("HEIGHT",DOCUMENT.HEIGHT)}
Posted : October 31, 2018 5:55 am
Topic starter
Thank you for the function. I'm testing it out on one of our smaller forms and it is working great pulling the obs from the form view. I am looking forward to seeing how much we can improve with more intensive forms.
Posted : October 31, 2018 7:42 am
