proc/ReplaceAll_With_(var/text="",var/target="",var/replacement="")
var/stringofchars=""
for(var/i=1,i<lentext(text)+1,i++) //go through the text incrementing by one
var/copiedText = copytext(text,i,i+lentext(target))
if(copiedText==target)
stringofchars += replacement
i = i + lentext(copiedText)
i--
else
stringofchars += copytext(text,i,i+1)
return stringofchars
1
2
Well, I re-wrote the function again (for like the fifth time), and it's now only 5 times slower than deadron's.
|
In response to Rockinawsome
|
|
You seem to want to be making this just... really hard and slow, and for what? It's so simple, and why wouldn't you use the most basic and fast measures for replacing text?
Profile results (total time) Those are the profiler results after testing your code and the more basic approach against the shorter string. Your approach is a bit less than 7 times slower. slower. Profile results (total time) After testing it with a longer string, your code faired slightly better than last time, but it can never be expected to fair better due to the nature of the system. The code used in these tests: #define DEBUG And the following ways you can improve the speed of your function: 1. store the length of the target. 2. use the shortcuts. += over var = var + value. you probably won't even notice this change, though. 3. check against first character of both strings before-hand. Honestly, I have no idea how you avoid runtimes with copytext() being asked to reach out of bounds all the time, but somehow you do. |
In response to CaptFalcon33035
|
|
CaptFalcon33035 wrote:
You seem to want to be making this just... really hard and slow, and for what? It's so simple, and why wouldn't you use the most basic and fast measures for replacing text? > Profile results (total time) Those are the profiler results after testing your code and the more basic approach against the shorter string. Your approach is a bit less than 7 times slower. slower. > Profile results (total time) After testing it with a longer string, your code faired slightly better than last time, but it can never be expected to fair better due to the nature of the system. The code used in these tests: > #define DEBUG And the following ways you can improve the speed of your function: Thanks for the tips! I re-wrote this again last night and made it a little bit less than twice as fast as the version posted here but I've got a bug to work out. Honestly, I have no idea how you avoid runtimes with copytext() being asked to reach out of bounds all the time, but somehow you do. Hahaha. Wow. Yeah I see that now. I don't know why it doesn't go out of bounds (or at least report on it) either. Edit* Btw, I was looking at your example and followed through the simple logic therein. I couldn't believe how simple the whole thing was--it makes perfect, easy logical sense, but it just never occurred to me. I'm hyper sensitive about using other people's code, and usually I don't, but I don't think my final product will be much different than yours, given how it seems the best possible answer. Edit#2 I hope this is satisfactory. I'm including this in my library I'm working on. //the credit for this goes to CaptFalcon33035. You can see my weak attempts below. Your function turned out to be twice as fast as deadron's! |
In response to Rockinawsome
|
|
No credit to me, everyone uses that. :P
Deadron made a good library, but it's weak/slow because he tried to build the entire thing around lists, and he succeeded at the cost of efficiency. He had some good ideas with the handling of text, though. Go through his library and have a shot at remaking most of his procedures, you will find that some (if not most) can be made to be pretty quick. They say not to reinvent the wheel, and when using a bytecode language, it makes perfect sense to use that which you have readily available from the language itself. Stick to the built-in functions before making one of your own to handle things in some odd way. Y'know, use the simple and efficient tools you have before you go making some crazy, complicated instrument that can do the same thing with more effort. |
1
2
Thanks for the tip! I'll check into it.