ConcurrentHashMap is part of Java and Java is developed by Sun (Oracle now I guess) and they have teams of engineers that are paid to make sure it's very fast. HashMap is probably one of the most widely used classes in Java so to compare it to the type of frameworks we're talking about is not at all a fair comparison. In any case, I'm not totally closed to the concept of frameworks if you can test it as you did and see that it improves your performance, but I'd be very doubtful that using frameworks will save much time in the long run and I would be completely shocked if I heard about a framework that performs better than code that was written by a good developer to do a specific task. Even with ConcurrentHashMap, you can get a performance improvement by writing your own. Google does that. They have a number of different hashtables that are designed to perform better given different scenarios. In your case, maybe 6000 per second is ok in which case you probably made the correct decision to use ConcurrentHashMap.

You forgot about option #3: Forget about frameworks and write the actual code that you need.

I have found that the overhead of understanding Frameworks generally outweighs their usefulness. I'm sure there are exceptions, but I have not found them yet personally. Many people use frameworks to do things that are absolutely trivial and I just do not get it. Generally, the requirements I see NEVER map to something that's out there exactly. If you can program, you just write what you need and it always works, it's fast, and probably most importantly you understand it completely.

Also, I totally disagree with the point that "Machines today are fast". I mean, obviously yes machines today are fast. But, in particular if you are writing a server side app, it's very easy to write something that does not scale. I have seen an app that used a lot of libraries and frameworks, etc that ran SO slow that could only process something like 1 request every 5 seconds. The same app was re-written (without using any libraries or frameworks at all) to be able to support tens of thousands of requests per second on the same physical server. Needless to say the guy who wrote the original app was fired and the guy who wrote the thing that supported 10s of thousands of requests per second got praise/bonuses/etc. The key to this kind of improvement was using the correct algorithms and data structures. When you just stitch whatever is free together you are rarely able to optimize things in such a way and you typically end up with a VERY slow app. I realize that not everyone is working on complex server side apps that need to scale, but even on front end apps, why make your app slower, lose the understanding of what you're doing, and understand some complex frameworks when you can actually write your own code in maybe less time? I mean, isn't this why so many apps are so slow. Every time i use an app that doesn't run instantly, I think about this concept. If everyone has this attitude that hardware is fast, then why do we all experience slow apps? It's because developer A thinks it's ok to reuse slow bloated code and it's still fast enough, but then developer B adds in a new feature that slows it down a bit more and uses a slow framework, then developer C adds in some other feature that slows things down further and in the end your code gets so bloated that even these really awsome machines can't run them in a way that the user expects.

I have seen similar problems occur when you do not use cache busting techniques. In other words, if your page refers to a static css file (e.g. ebay.css), then ebay.css is updated. Your browser will only update it when the cache expires it. The solution is to add a timestamp or random text to the end of url. Instead of referring to 'http://www.ebay.com/css/ebay.css' refer to 'http://www.ebay.com/css/ebay.css?[timestamp] or 'http://www.ebay.com/css/ebay.css?[random]

I know this is not a popular idea with a lot of people, particularly those working in places where "OMG speed is critical," but Python's execution speed just doesn't matter compared to its readability and time/LOCs required to get up off the ground and running.

I have heard this perspective before but found that when you have a team of developers that share this philosophy, you end up with VERY slow software. When you are writing software used by one person maybe you can focus on readability, but if you're dealing thousands or millions of users, forget about it. Readability does not have to come at the cost of efficient code either. There are very few occasions where making code fast makes it very confusing. In fact, I would argue that there is a lot of slow code that is very confusing to me. If people take the time to optimize it, it usually is easier to understand because there are no un-needed execution. In these few cases where very fast code is a little hard to understand, you just need to add a few lines of documentation to explain what you're doing.

I have not seen a study that discusses the cost of nuclear power that does not factor in the cost of employing well-educated people to run the plant. I'm not sure where you got this idea, but every study of the cost of nuclear power has to include the capital costs (costs of building, designing the plant) and operating costs which includes the cost of employing well trained specialists to run the plant. Typically, nuclear power has fewer operating costs than Coal or other sources of energy production, but higher capital costs (up front costs for building the plant itself).

Ok, if my math is correct then isn't this ridiculously expensive? Maybe we should, oh I dunno put the solar panels on people's roofs? Or better yet, use nuclear power which is cheaper and produces no C02? I realize you get a benefit by getting direct sunlight 24/7 in space, but there still needs to be some sort of cost/benefit analysis done here.

Maybe the private option (Google) will put the public option (The Library) out of business. It's kind of a reverse of the healthcare debate.

Why does it have to be one or the other? Most people are willing to pay for really good content (cable tv, movies, music). For not so good content, most people are not willing to pay (personal youtube videos, blogs, etc). The main, really cool thing about the internet is that it allows for extremely cheap distribution of content (whether it's free or pay). So, the New York times doesn't need to have a massive printing operation for an online service. The cable company will not need to run fiber to your house just for tv (I realize you might have internet provided by your cable company...) But the point is, if you pay some internet provider, you then get access to the ability to download all content in theory. This reduced cost allows for advertising to fund many things that could not be funded by advertising previously. So, to sum it up some content will be free, some will be pay, but at least we'll all save the expense of distribution (or much of it) by having a common distribution channel for content.

...the company has nothing to gain by disseminating this kind of information.

I would imagine it would be a deterrent to other employees regarding "violations of company procedures regarding expenses reimbursements". So that might be the reason for disseminating the info.

I live in an 'at-will' employment state, so I know that they have no legal recourse to keep me. I am concerned about the references they could give in the future

Just forget about it. You can get references from the co-workers who you are still on good terms with. If your boss is the one causing the problems, I assume that in 7 years, you had at least one other boss or supervisor that you can use as a reference.

1.4 million dollars, not exactly pocket change, even to Microsoft.

Given that Microsoft has $37 billion in total current assets as of the end of Dec '08. I think they'll survive if it IS only $1.4 million.

spill proof cup holder too? I've always wanted one of those.

This is one reason the computer industry really helps keep the employment numbers high. Unlike the auto industry, employees can much more easily go to a new company and contribute right off the bat. So, when you read about these kind of layoffs just think that it's a good thing because the employees will end up at a place that is setup better in order for them to succeed.

This is not Micron, this is: MPC: http://www.mpccorp.com/ that is going out of business.

That is true, SSD would not have this problem.