Competition #1: Reversing a string

[FourthWorld]

But this is my concern, if a scenario has an impact on the performance this impact should be at about the same for all functions.

As far as I can tell, all contributions to this thread thus far are using the same variable as their source, so it's about as even as one could expect.

There are, however, nuances which should be kept in mind when doing this sort of testing, but which are difficult, if not impossible, to account for when attempting to measure them.

The role of the OS in caching instructions and data is one, and we might see some small benefit from alternately reversing the order in which each of the two versions is called. But even then, we can expect slightly different results when running during a long session and when running fresh from a cold boot.

And then of course there's the impact of the many background tasks that most computers will be running concurrently with any test we'll be running, eating CPU cycles behind the scenes.

I don't believe it's possible, or at least practical, to try to account for such subtleties. Dick Kriesel may be able to come up with a way to minimize their impact (he's an uncommonly clever thinker), but I don't believe we can eliminate their effects entirely.

So when benchmarking we must be willing to accept loose approximation as the only outcome possible. Where we find significant advantage we're probably onto something useful, but where the results are frequently close we can never be sure whether it's because of the algo or the side effects of other things happening on the system.

FWIW, some years ago Wil Dijkstra took the time to post three interesting sets of tips on performance to the MetaCard list (the old name for what has since been renamed "LiveCode"):
http://lists.runrev.com/pipermail/metac ... 04415.html
http://lists.runrev.com/pipermail/metac ... 04469.html
http://lists.runrev.com/pipermail/metac ... 04539.html

Of those, I found the last one especially interesting, as it describes the impact of variable allocation and access on overall throughput.

Since LiveCode makes doing so many things so easy, we often take for granted the impact of seemingly small things like variable access, but Wil's third article illustrates well how even statements that seem simple enough can have an impact on what the engine is required to do to fulfill the request.

The sort of experimentation encouraged by threads like this one can be very helpful in identifying good habits to adopt in coding. Thank you for starting this discussion.

[[-hh]]

..........

[FourthWorld]

By the way, is the list still a main place for the MC/RR/LC 'nerds'? Yes? Wouldn't it be better, not to say most efficient, to move to here, in this forum (within a new subforum)?

Some people prefer email as a venue, others prefer the Web. RunRev provides both, and they're also very supportive of the growing LiveCode community at Stack Overflow:
http://stackoverflow.com/questions/tagged/livecode

And then there are various special interest groups spread about, like the Rev Interoperability Project forum at LiveCode Journal:
http://livecodejournal.com/forum/

The Game Development Forum:
http://livecodegamedev.net/

Also on social media:

LiveCode User Group in Facebook
https://www.facebook.com/groups/livecodeusers/

LiveCode Community on Google Plus:
https://plus.google.com/u/0/communities ... 0269230218

LiveCode Developers Group on LinkedIn:
http://www.linkedin.com/groups/LiveCode ... pers-50811

LiveCode's taking over the world - we can't expect its community to fit into a single venue.

[[-hh]]

..........

[[-hh]]

..........

[rkriesel]

Here's a version that you could use or adapt for competition#1C.livecode.zip

Code: Select all

command reverseChunks @rString, tChunkType, tDelimiter
    -- tChunkType has default "line"
    -- tDelimiter has default that depends on tChunkType
    local tIndex, tChunks
    if tChunkType is empty then put "line" into tChunkType
    switch tChunkType
        case "word"
            repeat for each word tChunk in rString
                add 1 to tIndex
                put tChunk into tChunks[ tIndex ]
            end repeat
            put space into tDelimiter
            break
        case "item"
            if tDelimiter is empty then put comma into tDelimiter else set the itemDelimiter to tDelimiter
            repeat for each item tChunk in rString
                add 1 to tIndex
                put tChunk into tChunks[ tIndex ]
            end repeat
            break
        case "line"
            if tDelimiter is empty then put return into tDelimiter else set the lineDelimiter to tDelimiter
            repeat for each line tChunk in rString
                add 1 to tIndex
                put tChunk into tChunks[ tIndex ]
            end repeat
            break
    end switch
    if tIndex > 1 then
        put empty into rString
        repeat with tIndex = tIndex down to 1
            put tChunks[ tIndex ] & tDelimiter after rString
        end repeat
        delete last char of rString
    end if
end reverseChunks

-- Dick

[[-hh]]

..........

[rkriesel]

You define 'word' as delimited by ONE delimiter (that is space). So for example "D"&space&space&"B" would have 3 'words' (first is "D", second empty, third "B"), for LC these are 2 words.

No, I didn't, as far as I can tell. When I feed that handler that input, the result has two words as expected. How did you get three?

Here's a new version, just for lines.

Code: Select all

command reverseLines @rString, tDelimiter
    local tIndex, tLines
    if tDelimiter is empty then
        put return into tDelimiter
    else
        set the lineDelimiter to tDelimiter
    end if
    repeat for each line tLine in rString
        add 1 to tIndex
        put tLine into tLines[ tIndex ]
    end repeat
    put empty into rString
    repeat with tIndex = tIndex down to 1
        put tLines[ tIndex ] & tDelimiter after rString
    end repeat
    delete last char of rString
end reverseLines

-- Dick