Showing posts with label Performance. Show all posts
Showing posts with label Performance. Show all posts

Wednesday, October 9, 2013

Bookishness & Geekiness

Internally I think of it as "My Geeky Book Club." And so I refer to it with my wife. But, the official name is LAJUG Study Group,  and last night the remaining faithful few finished up the Performance Book:

Now, our group will take a little break, and read a few articles, specifically: 
Paul Graham is a Technologist everyone should know about. Read his essays, if you haven't already. The link above will give you a start. He's a successful entrepreneur and now runs Y-Combinator , which is the best incubator for tech startups to get into. Not so much for the money -- you won't get that much -- but for the in-house expertise on starting tech companies, which is incomparable, and invaluable. 

Invaluable, in that it can't be valued, because it's value is too high. That's one of those problem words that always bothers me, because there are other reasons I can think of why something might be invaluable. For instance, working at a multi-billion dollar enterprise is experience that is invaluable: it can't be valued, because it is worthless. They lied about their desire to transform their technology, or at any rate they have no serious desire to step outside of their comfort zone and really accomplish much of anything. So the time spent working there and the experience overall is invaluable. This is another word to put on my list of peculiar english expressions along with inflammable, which means flammable! But we don't want to get confused here and we need to get back to geekiness and books and articles!

After next weeks session on the two articles linked above, we'll move into BDD and Cucumber. My copy has arrived from Amazon, but I haven't imbibed yet. So comments will have to come later.

As to last nights discussion, none of us are too enamored with the Performance Book, so we ventured fairly wide in our chatting.

One early topic was a comparison of several books from the past, and what was learned from them.  I noted that the Azul presentation, in my view, was far superior to this book. I felt that the Azul presentation answered questions and raised my understanding about Java Performance and Garbage Collection. In contrast, while this book answered some questions and improved my understanding somewhat, for everything I learned, I became aware of ten more questions, issues, and conditioning factors, which were NOT explained. Thus I was left with the feeling that in some sense I knew less than what I started with. Yes, I had gained knowledge, but I had gained more awareness of how lacking that new knowledge was than I had gained in new knowledge. This is kind of a difficult point to explain succinctly, but the pattern is: to understand A, you must understand Q, R, S, T, U and V to enter into a proper comprehension of A and it's implications. And here is are a few more details about A. But in the meantime, if you want to know about Q, R, S, T, U, and V, please consult the references at the chapter end. That is the pattern of what I felt from reading through this Performance Book.

By contrast, with the Azul presentation, I learned basic principles, and then saw an analysis of existent JVMs in the context of those basic principles. That's an extraordinarily good structure for any presentation. And it didn't leave me with tons of unanswered nagging problems and issues.

Another member noted that with the Generics book, it had been confusing, and he concluded that the Java community should have "just said no" to Generics.  I've always found them confusing as well. And I prefer keeping a language simple. 

He also noted that with the Concurrency book, while many of the corner cases were disturbing, there were lots of tips and "don't go there" advice that was well worthwhile.

Then there was some discussion about NRU: Not Recently Used. That's kind of interesting, this this is distinguished from the LRU (Least Recently Used) algorithm with which we are all familiar. Apparently, NRU is less precise, but has less bookkeeping overhead. 

Everyone was kind of surprised to learn that with a Java start command (-XX LargePageSizeInBytes) you can alter the page size all the way up to a Gigabyte! Not sure when I'd want to do this, but it's quite interesting. Perhaps an application might be able to tune to page size. Have to think about that one.

On p. 549, we got hit with a countervailing opinion that "pessimistic locking may provide better performance." But the conventional Whiz-dumb has it that optimistic locking will provide better performance. We discussed this for some time and came to see that really it depends on what the statistical likelihood is of lock failure, in your particular environment. If you're likely to fail on a particular lock, then it actually improves performance if you pessimistically lock! But I don't think anyone ever notes this nearly obvious fact, or stops to consider what their particular environment likelihood of failure is. 

So, that wraps up a difficult, demanding, and marginally rewarding read. I'm still a better person for having worked through it. But I would really love to take the Azul presentation and compare it to the Book chapters on the JVM. Perhaps, if Azul provides us with their slides, I'll do that.

I Remain, Ever Reading, and Ever ...


Wednesday, September 18, 2013

Geek Book Club: Java Performance

A Users Group is a bit low-tech, but still an excellent way to improve technical ability. This is re-demonstrated by the advent of agile techniques such as pair-programming, and Mob Programming. What is Mob-Programming, after all, but a sort of Users Group working on the same problem collaboratively, using only one keyboard! I have reservations about the value of  MBA-hole touted "teamwork," since it is often the last refuge of the incompetent; No better means of blame-shifting has ever been invented than the "teamwork" of a committee. But clearly there is a place for collaboration. And a Users-Group is a self-selected group of interested valuers of a particular technology.

I go regularly to a local Java Users group, which has a weekly Study Group, whose present book is on Java Performance. So, on Wednesdays, typically, I blog about the Tuesday night's book discussion. This week we're on Chapter 10, about performance on the Web.

Since I haven't blogged about the book at all until now, I'm going to generalize my impressions on the first ten chapters. This is not a book for the faint-hearted. It's very a very dense, tough read. I made it through about chapter 5 or 6 without serious problems, but got slogged down at that point, and only picked it up again here at Chapter 10. And what I learned was limited and somewhat frustrating. I can't entirely blame the book. Part of what limited my learning was the mere fact that an almost overwhelming number of tools are discussed in considerable detail. Now, if I had the time to use this as a tutorial, and work through those tools, my learning would have been much greater. For that, I'll take the blame. But the book raises a number of very tantalizing details which are not presented in sufficient detail to be really grasped or understood. On the positive side, I'm glad to know of the existence of all these tools. I'm also glad that I know where to turn to find all the tools and things-to-do to monitor a particular aspect of the performance of an environment. But, of course, this is a dwindling asset: as time passes, the list will logarithmically decay in terms of usefulness. The part that is frustrating is that many topics are referenced obliquely -- enough to raise them as a point of interest, but not enough to really grasp what is going on. I'll try to post an example of this next week -- in the interests of keeping this post manageable.  Back on the positive side, there are many tips and tidbits scattered through the text.

Last night, for instance, we read with considerable interest that enabling the Java Security Model resulted in a 33% performance degradation. That's much more overhead than I would have guessed. We also learned a cool trick for avoiding the 404 error associated with lack of a favicon. Provide a 1x1 pixel blank icon! Now that is way cool! And the whole group agreed.

My experience working through this book are shared by many other club members, by the way. One of them was posting to potential visitors not to judge the club by this book!

I Remain As Always,