Sunday, January 31, 2010


Just wanted to post that I put a link to my resume in the links portion of the page. It's in Google Documents, so anyone can save a copy in any of the supported formats.

I'll try my best to keep this up to date as my skills change.

Sunday, January 17, 2010

Coding Styles and D

Well, I've been working on some D code of late...nothing too interesting except I'm working on a compression algorithm. I'll get to that when I figure it out, but one thing I did was I wrote some code to do RLE compression, which is very simple and very effective on the right types of files. However, I was noticing that the code wasn't running very fast and using an insane amount of memory. For a enwik8 file that was cut in half, it took 26 seconds to encode and that was my best effort. So, I asked for help as I thought there was something seriously wrong and I didn't know if it was my fault or a problem with D in either the compiler or the standard library.

Turns out, it's both.

What was happening is that I was creating a lot of small arrays and concatenating them, which isn't the most efficient way to do things. I was under the assumption that basic operations like that would be fairly efficient since they're part of the language. I was wrong. Apparently the garbage collector isn't quite up to snuff yet, so it didn't do it's job properly. So, I followed the advice that I got when I posted to the digitalmars.D.learn newsgroup (Posting here) and I got a tremendous speedup. After I was done with the changes, I managed to get the time down to less than 2 seconds for encoding and decoding!

Now, where do coding styles come into play? Easy: I was coding as if I was developing in Java or Perl vs. a systems programming language like C. In those languages, array/stream/whatever concatenation probably would have been the norm, at least that's the way it seems in Java when I work with strings, and you get acceptable performance. In C, you can't do that so you have to do things differently, specifically you have to handle all memory allocations manually. When I switched to something more similar, my code became much more efficient.

Boy, this makes me wish I did more C-level coding at work.

Thanks again to all those who helped me out with this little problem!

Labels: , , ,

Thursday, January 07, 2010

Two Interesting Posts/Quotes

First off, I think I figured out my new years resolution: if I find an interesting article/quote I may want to blog about, I should keep track of it so I can link to it.

Now, to discuss the two things that I can't link to right now, I recently came across two things that got me thinking. The first was how TDD is pointless. I had agreed with one point and that is that you can set your API in stone too early in development, which did make sense to me at the time. The second is a quote from someone who worked at Sun that alluded to the fact that formal practices and techniques, such as UML, may not necessarily improve the development process as in the experience of the person making the quote, what he has seen developed by people developing in their free time, with a potential lack of formalized processes/best practices, being of higher quality that those that worked in a corporate environment with formal processes.

These got me thinking a bit. First off, it hit me a couple days after the TDD article that I incorrectly agreed with the API point that was made. You see, I had worked on some code where I did write tests, however as I wrote the tests and used the functions I had written, I discovered I didn't like my original interface and changed it. So, perhaps by writing out tests beforehand, one can interact with the API and get a better feel on how well done it is?

I also write code in my free time in a more relaxed mode. I still do things in a certain way, but I don't force myself to work within a standardized process. I think this allows me to conceptualize the problem better and come up with better solutions. Also, and I think this is a key point, I think that because in a more relaxed environment people tend to code without a formal design more often, they can see how the code will really work and perhaps execute the code more thus seeing how it really behaves vs. how you think it will behave based on the design. I'm not saying this is a good practice, but perhaps spending less time on documenting a design and more time coding produces better results? Of course, I would be writing/testing/executing the code in small chunks as I can only imagine the nightmare if I wrote several hundred lines of code and then tried to run it.

Of course, I do enjoy writing small amounts of code and executing it frequently. It lets me make sure that every step behaves exactly how I want it to.

Food for thought.