Page 1 of 1
What's the most efficient way to handle property diffs?
Posted: 26 Jun 2021
by ForgottenClank
Hi guys!
I am currently refactoring a lot of my code and am wondering what the best way for handling property diffs would be. At the moment I am using std::map and std::bind which someone suggested on the dev forum a long time ago, if I recall correctly. Is there a way to do this more efficiently or is this as good as it can get?
I am not a professional programmer so maybe I am missing some basic terminology here that would help me answer my question with a quick google search. So throw it at me if this problem has a specific name.
Cheers,
Adam
Re: What's the most efficient way to handle property diffs?
Posted: 26 Jun 2021
by orthodox
I think the most performance-efficient way is by using plain C and avoiding function calls for each diff. A single function processing all the diffs in a loop containing a big switch statement.
Re: What's the most efficient way to handle property diffs?
Posted: 26 Jun 2021
by ForgottenClank
orthodox wrote: ↑26 Jun 2021
I think the most
performance-efficient way is by using plain C and avoiding function calls for each diff. A single function processing all the diffs in a loop containing a big
switch statement.
Oh sure, I forgot about that! I am trying to avoid a switch statement, though, to increase reusability of my code. I am wondering if there may be a different way.
Re: What's the most efficient way to handle property diffs?
Posted: 26 Jun 2021
by rcbuse
I have a huge switch statement. But, its auto generated. I've automated out a bunch of the tedious stuff. I parse the motherboard.lua file with some python and generate the switch. I also auto generate the texts.lua from the motherboard.
Re: What's the most efficient way to handle property diffs?
Posted: 27 Jun 2021
by ForgottenClank
rcbuse wrote: ↑26 Jun 2021
I have a huge switch statement. But, its auto generated. I've automated out a bunch of the tedious stuff. I parse the motherboard.lua file with some python and generate the switch. I also auto generate the texts.lua from the motherboard.
Hm, maybe that's the way to go. Thanks!
Re: What's the most efficient way to handle property diffs?
Posted: 27 Jun 2021
by pongasoft
There is no magic in C or C++. Unless you measure you cannot tell what is faster. Having a big switch statement may be the most efficient in some situations but then it depends what you do in the various case branches. It also depends on how many properties get changed every batch, which is why using property diffs (rather than reading every property value every batch) should in general be way faster. How many properties are really changing absolutely every batch? If you are expecting a property to change every batch, I would advise to not include it in the diff but simply read it at the beginning of the batch...
In this day and age, memory layout seems to be more of a factor than number of instructions. If you have a big switch statement where the case statement keeps on jumping all over the memory it won't be faster...
Also you have to remember that the code gets turned into bitcode which is them compiled by Reason Studios into the final executable so you do not have complete final say in what the machine code will be.
Personally, I don't think you should worry. Write the code that makes sense to you and is easy to maintain. Yes a big switch statement will work but if you go down this route, I would also strongly suggest generating it with a tool. If you start having performance issues, then I would advise trying to find out where the bottlenecks are before assuming it is the property diff handling section...
I personally use a map where the value is a Property object that has an "update" virtual method
see on github (measurement on my local machine, so not general, seemed to indicate that calling a virtual method was faster than a bind). Does it make my REs slow and unusable? Certainly not. Is is slower than a switch statement? I don't know but I don't care because there is no performance issue with my devices... It makes my code way easier to read and maintain.
Re: What's the most efficient way to handle property diffs?
Posted: 27 Jun 2021
by buddard
I've profiled many of my REs over the years looking for bottlenecks, and the time spent in reading the property diffs has always seemed to be completely negligible compared to everything else the RE does. So I concur with the view that it doesn't matter, and I just try to write code that's easy to understand, debug and maintain.
Inside the "diff loop" I store the tag, value and object ref in local variables. Then I have an if-elseif-elseif-... for the object ref, and within each of those clauses I just write a large switch statement by hand. It's really simple, all it does is set values on the different objects that make up my device. I use a couple of inline functions to make the value conversion shorter to write/read, like getFloat(value), getInt(value), getBipolar() etc... And that's it!
Re: What's the most efficient way to handle property diffs?
Posted: 27 Jun 2021
by rcbuse
buddard wrote: ↑27 Jun 2021
I've profiled many of my REs over the years looking for bottlenecks, and the time spent in reading the property diffs has always seemed to be completely negligible compared to everything else the RE does. So I concur with the view that it doesn't matter, and I just try to write code that's easy to understand, debug and maintain.
Truth.
Re: What's the most efficient way to handle property diffs?
Posted: 27 Jun 2021
by ForgottenClank
pongasoft wrote: ↑27 Jun 2021
I personally use a map where the value is a Property object that has an "update" virtual method
see on github (measurement on my local machine, so not general, seemed to indicate that calling a virtual method was faster than a bind). Does it make my REs slow and unusable? Certainly not. Is is slower than a switch statement? I don't know but I don't care because there is no performance issue with my devices... It makes my code way easier to read and maintain.
I think this is what I was hoping for. Thanks! I'll take a look at your code