Software. Efficiency. Scalability.

Yesterday, Apple had a big a party where it finally announced iPod Touch+ iPad.

The device, praised by many as the next best thing since beer, has finally been shown to the public. It’s a glossy, shiny, stunning device with absolutely no new features compared to iPod Touch! Well, drop down menus are improved, and some apps got redesigned. However, waking up this morning after the party I started thinking about what it doesn’t do for me:

1. No web cam. Just like iPhone, it lacks a frontal camera needed for video conferencing.
2. No instant messenger. This is getting ridiculous. Even though iChat sucks it’d be still better than nothing.
3. No multi-tasking. Ever had friends send you links in the 3rd party instant messenger you have to use? I’d expect a $500 device to be able to open a browser window concurrently.
4. No Flash. I understand the politics of it, but as a consumer I just don’t care . Flash, like it or not, is an integral part of the web environment now. When my significant other uses her iPhone to pick a restaurant to eat at while we’re out, she can’t read half of the restaurant sites and menus because so many are flash-based. A modern tablet must support it.
5. No USB port. Why, in 2010, can’t I hook up my favorite USB keyboard to a tablet? I have no idea.

It looks nice on the paper. But just like Jobs said it himself last night:

“Now some people thought that was a netbook — the problem is that netbooks aren’t better than anything!”

Well, the next morning reality is that the iPad is not much better than anything either. It’s not better for web browsing due to the lack of Flash. It’s not better for doing email since I can’t have browser and documents open while working on an email. It’s not better for staying in touch with your friends since it lacks instant messenger and a web cam. It’s not better than Wii for playing games with my friends. It will never beat PS3 and XBOX at console games graphics, nor it is supposed to.

What’s left? iTunes. I would argue that iPhone and iPod are a lot more comfortable for music listening. iBooks. Well, this is something that remains to be seen. Even if it’s great, it’s such a minor feature compare to the all things iPad lacks.

Overall, there is a lot to be desired. I hope that Google, or whoever else comes up with the next best thing since beer, will address these issues.

Don’t ORM me, bro!

Not a day passes without people coming up with new ways to avoid SQL, to hide it from their sight, to banish it behind a layer of abstraction. ORMs such as ActiveRecord, Hibernate, and ADO.NET EF came to rescue. Anything but SQL! Why? Because we all know that SQL is ugly, complicated, not portable, scales poorly, and can cause Bovine Spongiform Encephalopathy if you write more than 2 statements a day.

ORMs, on the other hand, make it all magical. You don’t need to worry about SQL at all. Just define your maps and data will magically appear in your objects or be stored you-know-where.

Just like with anything else, ignoring problems provides little relief in the long run. Relational databases are delicate creatures. They require understanding of how they work. There are tools to make databases behave correctly. Whether it is hinting indexes, sending batches of data, or using prepared statements, there are interfaces for all of those tasks.

There are many little bells and whistles that help your database function better. All these tools are there  for a reason. You can’t shrug all these features away with an ORM and expect your project to work smoothly and scale properly when you hit volume.

Examples

Let me give you a quick example. Relational databases are generally bad at processing one record at a time and too many records at a time. Here is what I mean.

1) Say we have a table Customers where we keep customers, each customer has a unique Id column. We would like to fetch 2 customers with Id’s 1 and 2.

Now, we can do it in this way:

select * from Customers where Id = 1
...
select * from Customers where Id = 2

or this way:

select * from Customers where Id = 1 or Id = 2

The difference in performance? Executing the latter query is about 99% faster than executing two former queries. If you do not believe me, write a simple test and see how much overhead you incur on executing a statement compared to the time it takes to actually execute it. The actual execution time for simple queries is minuscule compared to the total time of execution.

2) Imagine another situation: You have a table PageVisit where you log every page visit. You have a lot of visitors and the table grows quickly. At some point of time you decide to delete all history that is more than 180 days old.

As is quite usual for databases, there is a simple solution:

delete from PageVisit where VisitDate < SYSDATE - 180

The problem here is very simple. If the PageVisit table is huge, the query will take a while to execute. The database will have to create an in-memory copy of the table first, due to its transactional nature. This is done so that ongoing selects can still see consistent data while the delete operation is executing.

If you are not worried about consistency you can speed up this operation by writing a script that executes a select, returns batches of Id’s for the records that need to be deleted, and then feeds those Id’s to a delete. On a big table a pump will execute much faster than a single query, even though it has to go through a client script that pumps the Id’s.

Conclusion

These are just two quick examples of how understanding SQL and how relational databases work can be important for your project. Even if you use an ORM of some sort, it’s extremely handy to understand what’s going on with your database, to check SQL logs, and to think about how you could optimize the queries. In the long run, it’ll make a big difference for your project.

Previously:  Understanding GC: freeing memory (Part I)

While GC resolved a lot of issues around freeing memory it made the situation a lot worse with allocation. Let’s be honest about it: developers have stopped thinking about allocating memory.

A lot of developers perceive GC allocated memory as, if not free, extremely cheap. If unsure — allocate. If unsure — copy. A deep copy, preferably. As the result, a lot of Java and .NET applications are extremely bloated.

Take a look at Visual Studio 2010 Virtual Memory struggle. Isn’t it fascinating? My Visual Studio 2008 runs projects in 150MB virtual space just fine, with the designer open to boot. The new version sets the acceptable threshold at 1.5GB. Just think about it: the new version requires an order of magnitude more virtual memory than its immediate predecessor!

Of course, GC allocated memory is neither free nor cheap. It can be less or more expensive under different circumstances. Here is a short list of things to keep in mind:

1. Do not blow through memory. There is no way around it. The more memory you consume the worse performance is going to be. It increases your memory footprint, takes longer to collect, reduces your CPU cache locality, and so forth. If you don’t need to allocate an object, then don’t.
2. Try and avoid write barriers. A write barrier occurs when an “older” object (usually older than gen0) is assigned a reference to a “newer” object from gen0. GC needs to know this fact to support partial collections therefore it needs to store information about such assignments. While not extremely expensive it’s not free either, if you are doing a lot of writes it can become a significant problem.
3. Try to keep your data structures simple. A compacting GC moves memory around, so it needs to update pointers to the proper after-collection locations.
4. Avoid semi-long living objects. A generational GC promotes objects from gen0 to gen1 and gen2, expecting them to live there for a while. One of the worst things that can happen is when lot of objects making it to gen1 and gen2 and then promptly die there. This triggers a lot of extra work for a GC.
5. Take care with your I/O memory. If you allocate a buffer and request a network read into it, the buffer becomes pinned. GC cannot move it since the driver will not see it. Pinning memory regions splits your arenas and makes it harder to allocate and compact memory.
6. Allocate large memory pieces carefully. When you allocate a large piece of memory (in .NET it’s over 85k) it goes to a Large Object Heap. LOH follows different laws. For instance, in .NET LOH is not compacted. Therefore, it can become fragmented and hurt your performance and memory footprint.

If you want your application to work fast, you need to have a full understanding of what is going on with your memory. A garbage collector can make it easier for you not to make common mistakes, but you still need to understand its laws and limitations.

Food and Drinks

Rock Bottom Brewery — we thought we’d get a sports bar or something like that, but the food was very decent and the service was simply amazing. My steak was perfectly medium rare. The custom beers were interesting, and the stouts were really good. Overall, impressive for a chain restaurant in the middle of a tourist area.

Weber’s Grill — an OK place with $3 beer specials. What is up with $7 shots?!

Atwood Cafe — not quite sure what’s wrong with the place. It has a fairly upscale menu and matching prices. Everything was off, from food to service to drinks. The ingredients and ideas were good, but it just didn’t seem to work out. The taste was all over the place. The only dish that I liked was Tuna Tartar. Then again, it wasn’t nearly as good as the tartar we ordered one night before at Rock Bottom.

Mary’s Cafe — an OK breakfast place. Their best feature is that breakfast is served until 3pm. The skillets are good. The french toast is mediocre. Does not accept credit cards but features an ATM machine in the middle of everything.

The Art Institute of Chicago

I like their Monet collection a lot. Every time I go there, it’s pretty much what I want to see. Honestly, if I were to go there by myself, I’d sit and stare at Water Lilies and Houses of Parliament.

We went around and looked at a lot of different collections. Yet again I realized that contemporary art is not my forte. If an artwork is named Untitled, it’s probably something I don’t like. Most of the works try to make a statement. I would rather just stare at the lilies.