Programming help

[XMEN Gambit]

Asha,

Code's clean and easy to read. Bonus points!
Trying to figure out why you're using strings instead of byte arrays. The compares are expensive, as you say, but you may need to do it that way so I'll reserve judgment.

Just kind of skimmed it but I did see an easy performance booster for you. In several places you have a loop that checks for a match, such as in setSignalTableElement(), intending to set a variable with the found position. But when you do find a match, you keep checking instead of breaking out of the for loop. That means you're wasting cycles, especially if you have only one match early. OTOH, if you're interested in the last possible match, then start your loop at the end of the range of values, work backwards, and still break out when you find a match.

[XMEN Ashaman DTM]

Hmm... had not considered just doing chars. Was trying to go "full C++" if that makes any sense.

I think you're right, Gambit. But wouldn't I lose the ability to look for variable string lengths? Doesn't a character array need clearly defined storage up front? I seem to remember that from C.

I wrote the for loops that way because I wasn't sure if I would have a separate function to check for duplicates in the "input"/"output" arrays. The functionality is there to allow duplicates in, and I wasn't sure how to re-write things to avoid giving the user the ability to input duplicates.


As for my code: I always try to be organized, because I usually make a lot of syntax errors. I have spent hours upon hours looking for a semi-colon due to improper syntax for a typedef'ed struct. Of course, now it's one of the things I mentally check for as I type.

[XMEN Gambit]

There's numerous ways of doing the "series of bytes" thing. If a variable length is important, and you're comfortable with it, might as well. Compare() might be working fine for you, so don't fret too much on that one. There are variable-length byte array objects available if you feel inclined to investigate.

However let's take the other point. Snippet:

Code: Select all

    for&#40;ii=0; ii<out_size; ++ii&#41;  
    &#123;
        if&#40;outputs.at&#40;ii&#41;.compare&#40;out&#41; == 0&#41;
        &#123;
            out_pos=ii;
        &#125;
    &#125; 

Only one value is in out_pos at the end of the loop. If there is a match at ii = 0, then out_pos is set to 0, and the entire length of the string is still looped through, looking for a match. If there's a match at 0, and another one at 50, then the first 50 iterations are wasted because the 0 is overwritten with the value of 50 before anything is done with it. Either way a lot of CPU cycles are spent on work that isn't being used.

You should see a big improvement by breaking out of the loop once the match is found. If you just do that, though, you may see different results than previous if there are multiple matches, because you'll be catching the first instead of last match. That's why you need to figure out if you want the last match, or the first match, from your string and work from that end of the string.

Or you could get more complex and decide that you want ALL matches. Bit of a redesign there.

[XMEN Ashaman DTM]

Gambit, you're absolutely right. For short arrays, it doesn't matter so much, but much more than about 100 entries, and it really bogs things down.