[X] My Assistant

Garbage collection makes me rage (the instant, not the manual kind, as "delete variable;" is also called garbage collection). I will reiterate: it's one line of code. int penis is not in use anymore? delete penis; That is not hard, people. And everyone who says: "Oh, but Java does it all for me!" Not it fucking doesn't. Its garbage collection algorithm isn't fail-proof, and in some cases it makes it worse. Also, Java uses just-in-time compilation, meaning that the fact that you're not deleting the damn variables is making your program slower.

AND AGAIN I CANNOT STRESS THIS ENOUGH: If you're not using Trees (Binary, B, B+, etc), DO NOT FUCKING USE RECURSION. There are very few instances outside of trees where a recursion can't be solved with whiles/fors/loops. Sometimes it's going to look ugly, but if you're writing code, you're doing it to be functional, not pretty. Pretty is secondary.

Actually, if the thing doesn't have to be lightning fast (like for example in the UI code), and the code has a high chance of having to be modified by not-too-bright programmers I work with, I often end up doing recursion exactly so it doesn't look ugly, because if it does, I'll have to go back to it every time another programmer breaks something.

This logic is the exact reason why Java sucks so much balls. I cannot stress this enough. This just encourages others to copy you. I've seen this countless times. You write a recursive code, others read it, and think it just makes it easier to read, and doesn't influence speed and memory. So they do it too (I had to convince a Computer Software Engineer last month that recursion eats memory, as he didn't believe it, simply because he was previously told it wasn't bad to code it anywhere, because it was "pretty code").

Furthermore, unless this is "in-house-code" it will be best to make it lightweight. I learned this from MS: "If it ain't broken, they'll break it." Your program can be just as fast as you think it should be; nonetheless, 30%+ of the market will think it's too slow and buggy. If you're selling your program you have to make it as lightweight as possible. If you're using more memory because you think computers can handle it, you're following the same path as Java and Firefox. It does not end well.

I'm not saying write everything in assembly, but no need to use all the resources simply because they're there. Realize this: a recursive method that calls itself 500 times with just a char stored in it will eat 4 gigs of ram. And 500 recursions isn't that uncommon, especially in databases. Not to mention the context switching will be noticeable, as opposed to a simple loop.

Conclusion: In house code that will be heavily modified - use recursion as much as you wish.
Shipped code - stay with loops.

Realize this: a recursive method that calls itself 500 times with just a char stored in it will eat 4 gigs of ram.

o.O Wow. I always knew recursion is crap, but I didn't know it could be this bad. I'll remember that.

o.O Wow. I always knew recursion is crap, but I didn't know it could be this bad. I'll remember that.

I just thought about what I wrote and that part is wrong. You'd need a string of 1000 chars for 500 iterations. Nonetheless it is common to have 50,000 nodes in database trees, and if you're continually iterating through them, you're pretty boned.

Either way, given that a while loop uses x bits of memory, a similar recursion will use y*x, where y is the number of iterations. This does not hold for nested whiles, of course.

This post has been edited by noahbody: Jan 6 2011, 04:30

I just thought about what I wrote and that part is wrong. You'd need a string of 1000 chars for 500 iterations. Nonetheless it is common to have 50,000 nodes in database trees, and if you're continually iterating through them, you're pretty boned.

Ah. That indeed sounds more realistic. (IMG:[invalid] style_emoticons/default/tongue.gif)
Nevertheless I still don't like recursion though. Not even in code that has still to be modified a lot. Not only it's pretty resource intensive, I think doing it when you don't need to is also kind of a messy way of working; and messy work is something that I've always forbidden myself.

(Err... well, only when I am programming, that is. :]])

I think you're writing code in different circumstances than I do (IMG:[invalid] style_emoticons/default/smile.gif)

1. In most of the places where I use recursion it's practically never deeper than 10 calls - usually UI thingy, or some operations on simple data parsing from text file. So additional data that's stored on stack doesn't eat that much memory, and it's all freed without any fragmentation when you finish the recursion. (As an aside, many people don't realize they have only so much stack space for each thread and I've seen bugs where the algorithm crashes because it's using recursion and running out of stack space, and then programmer hasn't the slightest idea what it means.)

2. Almost all of the code I write can be expected to be visited multiple times by other programmers, and rewritten by them at least a few times. As you wrote, in many cases non-recursive code is ugly and hard to understand and maintain, and it ends with people coming to me saying they have no idea how it works, or rewriting it and doing it wrong and then it breaks and I have to fix it. I usually prefer leaving the recursion in - but if for performance reason I have to make it ugly, I usually keep the recursive version around, either commented out or in #ifdef 0 , or something like this, and I tell everyone to look at the recursive version to understand what it does, then either understand the non-recursive one with this knowledge, or work with the recursive version and flatten it again to speedy code later. Anything to make it more understandable and maintainable.

Besides, when I'm done porting the game, I profile it and check for things that can be speeded up easily in typical moments in game. Then testers play it and if they encounter any place where it's slow, either because the algorithm is slow, or if or if they play on Macs with different hardware and something else changes, they complain, and I revisit the issue and fix it. (For example, software for ATI cards on Macs doesn't check what registers are really used in vertex shaders, and if X are declared in a table, it will make space for all of them, and if the compiled program ends up with more than 256 registers, it'll fallback to software. I test on NVidia cards and this doesn't happen on them, so sometimes I have to massage shader code taken from PC manually to make the tables smaller.)

1. In most of the places where I use recursion it's practically never deeper than 10 calls - usually UI thingy, or some operations on simple data parsing from text file.

These both things involve building and/or visiting a tree (of UI components or tokens), so using recursion makes sense here. I think both of you are saying the same thing (IMG:[invalid] style_emoticons/default/unsure.gif)

Yeah, mybe I just never encountered the example of bad use of recursion noahbody is angry about. Say, maybe the programmers I work with aren't that bad after all (IMG:[invalid] style_emoticons/default/smile.gif)

Your mother is so fat, the recursive function calculating her mass causes a stack overflow

For example, software for ATI cards on Macs doesn't check what registers are really used in vertex shaders, and if X are declared in a table, it will make space for all of them, and if the compiled program ends up with more than 256 registers, it'll fallback to software. I test on NVidia cards and this doesn't happen on them, so sometimes I have to massage shader code taken from PC manually to make the tables smaller.

Speaking of which, video cards are another thing that is ripe with bad programming. When I did my NVidea research internship, I had to optimize their cuda compilers. You have no idea how much wrong there is in it. And you think codes with whiles instead of recursion are ugly? Wait til you see their compilers. Not. One. Fucking. Comment. Fun fact: early on, their compilers did not properly assign registers. "But Mr. Body, what do you mean by that?" you may ask. Well, they assumed that the hardware had an infinite number of registers. Yes, it was that bad.

These both things involve building and/or visiting a tree (of UI components or tokens), so using recursion makes sense here. I think both of you are saying the same thing (IMG:[invalid] style_emoticons/default/unsure.gif)

Could be - I never do UI - I program the backbone of systems more so than the presentation.

Yeah, mybe I just never encountered the example of bad use of recursion noahbody is angry about. Say, maybe the programmers I work with aren't that bad after all (IMG:[invalid] style_emoticons/default/smile.gif)

The people I programmed with are not bad. The reason I'm mostly angry about is that I program a lot in real time, in which performance is key. Every cycle counts. Every bit counts. Due to my focus on optimization, every time I see something that would not cut it on RTS, it seems kind of broken. And it is my firm belief that if everyone coded with RTS in mind, codes would be much quicker and less bloated, enabling one to implement more better features. If every code followed RTS standards, the world would be a better place.

Your mother is so fat, the recursive function calculating her mass causes a stack overflow

This is brilliant. (IMG:https://forums.e-hentai.org/style_images/fusion/folder_post_icons/icon14.gif)

Speaking of which, video cards are another thing that is ripe with bad programming. When I did my NVidea research internship, I had to optimize their cuda compilers. You have no idea how much wrong there is in it.

I've read through PhysX sources right before NVidia bought this tech, hoping to make it fail less with a game we were developing then - it had more comments, but most of them were 'this is a hack for demo xx/yy/20zz' or' I have no idea what this does' or 'DON"T TOUCH THIS!'.

(IMG:https://forums.e-hentai.org/style_images/fusion/folder_post_icons/icon14.gif) to the rest of it (IMG:[invalid] style_emoticons/default/smile.gif)