Optimization should be done where the bottleneck of the problem is in a loop or the algorithm, otherwise you're just wasting your time optimizing something when you could have spent that time working on some other aspect of your program.
| |
Rushnut wrote:
You're still calling copytext at LEAST one time too many, in fact the more I peer at it, you could probably pull two of them out, get the same functionality and cut down greatly on the CPU used. I know, but its a utility, the difference won't matter much. Why even try to optimize mine or change mine when I could just use split? When I glance at split, I don't understand exactly what its doing inside and out, therefore I'm not really using it because what matters more to me in this utility is code readability so that I can continue to manage and maintain it. Considering readability is more important than performance in this case, I prefer to keep my original implementation. | |
FIREking wrote:
Rushnut wrote: But that's completely ridiculous. I hadn't really looked at either of your codes before today (Although I have used F_A's previously in a project), and I understood the methodology and reasoning behind F_A's code a lot better than I did yours. It's your extra usage of copytext and unnecessaryness-nuss that is what actually confuses me. If you're creating a utility (Something you hope other people to use) the very last thing you want to be doing is making it intentionally worse than it could be, for any reason. | |
Magnum2k wrote:
Optimization should be done where the bottleneck of the problem is in a loop or the algorithm, otherwise you're just wasting your time optimizing something when you could have spent that time working on some other aspect of your program. Spending your time on menial boring tasks like shaving 0.001 CPU off your next best proc is certainly time consuming, but being lazy and sloppy in your programming just so you can add the next best jutsushameha, is certainly a lot worse. Plus it's not as much about optimizing your code pre-emptively, it's just about learning and teaching yourself the best possible ways of handling a situation so your skill as a programmer slowly progresses upwards. | |
Honestly, I don't use text handling very much anywhere.
But it's such a waste of time to do research before working on something, especially when you're not actually working on anything. | |
The time differences are pretty pointless, considering this probably won't be critical path code.
| |
Meh, whatever. The utility is only for me haha.
I probably should just refrain from sharing any code snippets. | |
Stephen001 wrote:
The time differences are pretty pointless, considering this probably won't be critical path code. Speak for yourself, I'm making Dictionary Grand Online Adventure as we speak. FIREking wrote: Meh, whatever. The utility is only for me haha. Please don't, I enjoy discussing this kind of stuff, even if it isn't what you intended to happen =P | |
Well, if you're making Dictionary Grand Online Adventure, you'd presumably compare the difference privately, and tweak as you find it to be an issue, because it's your critical path. It however won't be Fireking's (unless he's done something /very/ wrong) or most people's.
What is a little bit absurd, is the notion that you'd spend time optimising and heavily scrutinising code that your players won't notice the differences in. Particularly considering that's time you could've put towards say ... actually releasing the game, so said players exist. Until released, the game has zero value to anyone. | |
Yours is very similar to split(), except for a few lines that add the custom delimiter functionality, and some things out of order.
// yours (minus comments) The main difference is that he moves the search up the string by changing the start point in findtext(), while you use an extra copytext() to cut the string from the front. That extra copytext() is what makes yours slower, I'd say. | |
If pre-optimization is the root of all evil then I have to wonder what pre-pre-optimization for the sake of pre-optimizing is.
| |
Hilarious. (Or ego-massaging, your choice)
| |
Ok well in terms of understanding F_A's split, I immediately have questions that I can't really answer instantly unless I actually go test them out...
1. What happens if there are a string of concurrent delimiters? Do we get empty list entries? That's bad in my case, I can't have empty list entries. 2. What happens if the last character of the input string is or isn't a delimiter? Do we get an empty list entry at the end? Do we get the last bit of string content at the end? 3. Why is there another list entry addition statement after the while statement completes? Those questions alone are the reason I wrote my own (which was really part of an exercise more than anything to get back into the swing of coding after moving from my house for 5 days straight, long story) I'm sure I could sit here, or you could sit here, and answer all three of the questions... either off the top of your head or through testing the case scenarios, maybe even modify it so that it fits my situation better. But the act of doing those things are the reason I choose to write my function. In a situation where I need to call this 90000 times, I will look at bottlenecks. Until then, I think this is fine to call a dozen times. | |
Ah you mistake my intentions completely then. I never intended to scrutinize such programming, I'd of left it and been happy, but replies in this post brought up the argument so I decided to actually compare and optimize.
I understand that optimizing menial stupid stuff isn't ideal, but like I said to Magnum, learning good practice is never a bad thing. So if I was making one of my random 10 minute boredom spree games, I'd probably spend my time over optimizing everything, so that when the day comes that I sit and start another serious project, I'll remember good habits and the best ways to approach problems and ultimately I'll be better off for it. | |
Yep, the first thing I'd do to optimize mine is just use two positions instead of refactoring the string.
| |
LordAndrew wrote:
If pre-optimization is the root of all evil then I have to wonder what pre-pre-optimization for the sake of pre-optimizing is. It depends. It's not much of an issue, as you haven't written any code yet. If your program is still in design phase, and say for example, you're deciding what data structure to use if you're going to be constantly deleting and inserting arbitrary items, then that is not pre-pre-optimization. | |
I don't see what's wrong with this situation:
1. People who aren't actually making games experiment with snippets to see what works better. 2. People who are making games can see the results and have the option to either: -A. Keep the technically slower code because pre-optimization is evil because of an article and that Stephen001 said it's pointless on the forums. -B. Use the better code. It may be pointless, but it's still technically better. If you just use better code to begin with, it won't even come up as a topic to be discussed. | |
I'd argue that doing such scrutiny in the first place is bad practice (much worse than whatever might've been gained from this exercise), and the public fanfare we give on this forums to that bad practice, makes it doubly so.
You have two groups of people here. One that makes games, and one that kind of potters about and messes with academic "what if". The problem here, is the interaction of the two, because the potters about and messes with academic "what if" group are obviously a lot more visual on the forums than the makes games group, and so to the outside, new programming reader, those "what ifs" get a lot more weight placed on than say ... actually just making the game already, and so the former group get fixated and embroiled with stuff that ... frankly doesn't matter for their case, and that kills projects, delays releases etc. I expect Fireking will do .. more or less nothing, as a consequence of the discussion that's occurred here, and instead, puts focus on actually releasing the game he's making. I'd expect all game developers to do that, unless they are in a position where they've released and are post-release optimising, or implemented something and it's unbearably slow and uses this kind of pattern. | |
Pretty sure I said that exact thing a few posts earlier
FIREking wrote:
You're still calling copytext at LEAST one time too many, in fact the more I peer at it, you could probably pull two of them out, get the same functionality and cut down greatly on the CPU used.
Magnum2k wrote:
In the same way everything makes your game faster? Less CPU usage allows you to add more features and functionality to you game. Full stop. No arguing about that anywhere, because if you do, you're wrong.
Like I said, if you manage the smaller details of your game, the bigger ones are much, much easier to manage (And as such you can be more lenient with them when you get frustrated :P)