Comments for Development at Guidewire http://guidewiredevelopment.wordpress.com A group blog from the Developers at Guidewire Software (www.guidewire.com) Fri, 20 Nov 2009 13:47:13 +0000 http://wordpress.com/ hourly 1 Comment on Compiling Try/Catch/Finally on the JVM by Taras http://guidewiredevelopment.wordpress.com/2009/10/22/compiling-trycatchfinally-on-the-jvm/#comment-660 Taras Fri, 20 Nov 2009 13:47:13 +0000 http://guidewiredevelopment.wordpress.com/?p=281#comment-660 interesting i guess it's all subject for another topic would you mind doing a blog on Studio performance and plans to improve it? :) interesting
i guess it’s all subject for another topic

would you mind doing a blog on Studio performance and plans to improve it? :)

]]> Comment on Compiling Try/Catch/Finally on the JVM by Alan Keefer http://guidewiredevelopment.wordpress.com/2009/10/22/compiling-trycatchfinally-on-the-jvm/#comment-658 Alan Keefer Thu, 19 Nov 2009 17:06:33 +0000 http://guidewiredevelopment.wordpress.com/?p=281#comment-658 It's almost certainly not worth fixing just for speed improvements; it's really just a small drop in the bucket compared to everything else going on. Maybe 1 or 2%, depending on how many issues there are on a given page and how frequently that code is hit? Maybe not even that? The main incentive to fix those will be, as you say, that some day you'll have to fix them if you want to upgrade to some later version that's fully case-sensitive (probably CC 7/PC 5/BC 4 will have a case-sensitive version of the language, though that's not set in stone by any means). It’s almost certainly not worth fixing just for speed improvements; it’s really just a small drop in the bucket compared to everything else going on. Maybe 1 or 2%, depending on how many issues there are on a given page and how frequently that code is hit? Maybe not even that? The main incentive to fix those will be, as you say, that some day you’ll have to fix them if you want to upgrade to some later version that’s fully case-sensitive (probably CC 7/PC 5/BC 4 will have a case-sensitive version of the language, though that’s not set in stone by any means).

]]> Comment on Taking Responsibility by Minh Vu http://guidewiredevelopment.wordpress.com/2009/06/25/taking-responsibility/#comment-657 Minh Vu Thu, 19 Nov 2009 08:53:04 +0000 http://guidewiredevelopment.wordpress.com/?p=265#comment-657 This is the right philosophy because the man behind it live up to it. Because people are led by example, so whatever philosophy a leader pursuit, it will works if and only if the leader himself is an example. This is true for Alan, Adolf Hitler and Dr. King :) even their philosophy are different. In my own little world and narrow view, I think that leader should be tough with his followers, demand nothing but the best from them, but taking the least when things go right and the most when things go wrong. The great leader should take himself out of the equation of what best for the company. Actively prepare his successors to take his place in case he's out. He himself is nothing but the catalyst for a great company and transform himself into the cooperate culture. Alan is great, the and what better is we're not done with him yet, we can get more from him. This is the right philosophy because the man behind it live up to it. Because people are led by example, so whatever philosophy a leader pursuit, it will works if and only if the leader himself is an example. This is true for Alan, Adolf Hitler and Dr. King :) even their philosophy are different.

In my own little world and narrow view, I think that leader should be tough with his followers, demand nothing but the best from them, but taking the least when things go right and the most when things go wrong. The great leader should take himself out of the equation of what best for the company. Actively prepare his successors to take his place in case he’s out. He himself is nothing but the catalyst for a great company and transform himself into the cooperate culture. Alan is great, the and what better is we’re not done with him yet, we can get more from him.

]]> Comment on How Much Do You Sweat The Details? by Minh Vu http://guidewiredevelopment.wordpress.com/2009/09/04/how-much-do-you-sweat-the-details/#comment-656 Minh Vu Thu, 19 Nov 2009 08:21:30 +0000 http://guidewiredevelopment.wordpress.com/?p=267#comment-656 :) If I get into Alan's head, I probably won't find my way out. This is an interesting thought which holds many implications. I doubt that complex decision like this should be made at any regular basis. This is like socialist government trying to set price for thousand of products on the market, no ways they gonna know how much a product will cost until someone pay for it. Upfront, you cannot tell how much time you can save, nor can you predict the possibility of such saving. We need a simple idea like capitalism, let supply and demand decide the price and in turn allocate scared resources efficiently. My personal take on this is to go with your first instinct, if you think there is a chance that your first instinct may be different from others, double check with them. If it's clear in your mind and that of your collages, go with it, if it would not works, everyone will understand why and will fix it. If you don't even have the first instinct, go ask Alan K. :) :) If I get into Alan’s head, I probably won’t find my way out. This is an interesting thought which holds many implications. I doubt that complex decision like this should be made at any regular basis. This is like socialist government trying to set price for thousand of products on the market, no ways they gonna know how much a product will cost until someone pay for it. Upfront, you cannot tell how much time you can save, nor can you predict the possibility of such saving. We need a simple idea like capitalism, let supply and demand decide the price and in turn allocate scared resources efficiently.

My personal take on this is to go with your first instinct, if you think there is a chance that your first instinct may be different from others, double check with them. If it’s clear in your mind and that of your collages, go with it, if it would not works, everyone will understand why and will fix it. If you don’t even have the first instinct, go ask Alan K. :)

]]> Comment on Compiling Try/Catch/Finally on the JVM by Taras http://guidewiredevelopment.wordpress.com/2009/10/22/compiling-trycatchfinally-on-the-jvm/#comment-655 Taras Sat, 14 Nov 2009 06:58:25 +0000 http://guidewiredevelopment.wordpress.com/?p=281#comment-655 Yeah we've noticed those 300 odd warnings when the server starts up :) So how much slower is it going to be? Is it 2-3 times slower? What I'm trying to establish, is whether it's worth going through the legacy code and fix all those case sensitivity issues, or leave it for the distant future when the management decides to upgrade to a version with full case sensitivity. Yeah we’ve noticed those 300 odd warnings when the server starts up :)

So how much slower is it going to be? Is it 2-3 times slower?
What I’m trying to establish, is whether it’s worth going through the legacy code and fix all those case sensitivity issues, or leave it for the distant future when the management decides to upgrade to a version with full case sensitivity.

]]> Comment on Compiling Try/Catch/Finally on the JVM by Alan Keefer http://guidewiredevelopment.wordpress.com/2009/10/22/compiling-trycatchfinally-on-the-jvm/#comment-654 Alan Keefer Thu, 05 Nov 2009 16:23:37 +0000 http://guidewiredevelopment.wordpress.com/?p=281#comment-654 Yeaaahhhhhh . . . that one's kind of an odd story. I believe (though I could be wrong . . . it was more than seven years ago) that GScript ended up case-insensitive because a very early customer requested that for our rules engine (which was all GScript was, at first). Unfortunately, in addition to being annoying due to namespace collisions, it's a bit of a performance drag. In previous versions of our platform, we implemented case-insensitivity via a CaseInsensitiveHashMap and a CaseInsensitiveCharSequence; basically, doing something like toUpperCase or toLowerCase all the time was too expensive, so we had to wrap Strings in our own object that could do a case-insensitive hash, and have a special Map class that knew how to make use of that. Even that, however, turned out to be a major performance drag. So for the version of the platform used in CC5, we killed off as many of the CaseInsensitiveHashMaps as we could, and instead replaced it with a fallback mechanism: we assume that the name typed into the source is the correct one, so we look the property up by that name in a normal HashMap. If that fails, then we fall back to looking through the property names to find the one that matches without regard to case. That lookup process is relatively slow, though, and happens every time that expression is executed. The upshot is that we were able to improve performance in the case where everything is in the right case at the expense of slowing down accesses where the case is incorrect. You'll notice that case mismatches also now generate a parse warning, so you can at least identify and fix those issues. I believe the current plan is to make the language fully case-sensitive in some not-too-distant future release. Yeaaahhhhhh . . . that one’s kind of an odd story. I believe (though I could be wrong . . . it was more than seven years ago) that GScript ended up case-insensitive because a very early customer requested that for our rules engine (which was all GScript was, at first). Unfortunately, in addition to being annoying due to namespace collisions, it’s a bit of a performance drag. In previous versions of our platform, we implemented case-insensitivity via a CaseInsensitiveHashMap and a CaseInsensitiveCharSequence; basically, doing something like toUpperCase or toLowerCase all the time was too expensive, so we had to wrap Strings in our own object that could do a case-insensitive hash, and have a special Map class that knew how to make use of that. Even that, however, turned out to be a major performance drag.

So for the version of the platform used in CC5, we killed off as many of the CaseInsensitiveHashMaps as we could, and instead replaced it with a fallback mechanism: we assume that the name typed into the source is the correct one, so we look the property up by that name in a normal HashMap. If that fails, then we fall back to looking through the property names to find the one that matches without regard to case. That lookup process is relatively slow, though, and happens every time that expression is executed.

The upshot is that we were able to improve performance in the case where everything is in the right case at the expense of slowing down accesses where the case is incorrect. You’ll notice that case mismatches also now generate a parse warning, so you can at least identify and fix those issues. I believe the current plan is to make the language fully case-sensitive in some not-too-distant future release.

]]> Comment on Compiling Try/Catch/Finally on the JVM by Taras http://guidewiredevelopment.wordpress.com/2009/10/22/compiling-trycatchfinally-on-the-jvm/#comment-653 Taras Thu, 05 Nov 2009 13:15:22 +0000 http://guidewiredevelopment.wordpress.com/?p=281#comment-653 give us more :) btw, on an unrelated topic what's the go with GScript in V5.0 of CC being not case sensitive, but if you use proper casing the manual says you achieve better performance? how does that work? give us more :)

btw, on an unrelated topic
what’s the go with GScript in V5.0 of CC being not case sensitive, but if you use proper casing the manual says you achieve better performance? how does that work?

]]> Comment on Compiling Try/Catch/Finally on the JVM by David Linde http://guidewiredevelopment.wordpress.com/2009/10/22/compiling-trycatchfinally-on-the-jvm/#comment-652 David Linde Wed, 28 Oct 2009 18:39:07 +0000 http://guidewiredevelopment.wordpress.com/?p=281#comment-652 I enjoyed the post, I am definately interested in more jvm details or new languages in general. I enjoyed the post, I am definately interested in more jvm details or new languages in general.

]]> Comment on Compiling Try/Catch/Finally on the JVM by Alan Keefer http://guidewiredevelopment.wordpress.com/2009/10/22/compiling-trycatchfinally-on-the-jvm/#comment-651 Alan Keefer Mon, 26 Oct 2009 07:00:39 +0000 http://guidewiredevelopment.wordpress.com/?p=281#comment-651 My vague understanding (according to my co-worker who did the first pass at the implementation) is that Java used to use a subroutine call for finally blocks, calling the subroutine at all the necessary places, rather than directly inlining the finally blocks as is done now (apparently the subroutine instruction isn't allowed in 1.6 bytecode). Apparently they ditched it because it made verification too difficult and too slow, though I can imagine that, as you say, it's still a serious pain despite that change. My vague understanding (according to my co-worker who did the first pass at the implementation) is that Java used to use a subroutine call for finally blocks, calling the subroutine at all the necessary places, rather than directly inlining the finally blocks as is done now (apparently the subroutine instruction isn’t allowed in 1.6 bytecode). Apparently they ditched it because it made verification too difficult and too slow, though I can imagine that, as you say, it’s still a serious pain despite that change.

]]> Comment on Compiling Try/Catch/Finally on the JVM by Alan Keefer http://guidewiredevelopment.wordpress.com/2009/10/22/compiling-trycatchfinally-on-the-jvm/#comment-650 Alan Keefer Mon, 26 Oct 2009 06:56:22 +0000 http://guidewiredevelopment.wordpress.com/?p=281#comment-650 Yeah, that one's definitely a bit nasty. Currently we model the Java behavior there, such that the exception thrown from within the finally blocks causes any previous exception to be lost. Since we're compiling our language ourselves, theoretically we could do something different there, like wrap the version of the finally block that's used to handle exceptions inside a try/catch(Throwable), such that if the finally block code is executing because of an exception and itself throws an exception, we could do something. I'm not entirely sure what that something should be, though. Yeah, that one’s definitely a bit nasty. Currently we model the Java behavior there, such that the exception thrown from within the finally blocks causes any previous exception to be lost.

Since we’re compiling our language ourselves, theoretically we could do something different there, like wrap the version of the finally block that’s used to handle exceptions inside a try/catch(Throwable), such that if the finally block code is executing because of an exception and itself throws an exception, we could do something. I’m not entirely sure what that something should be, though.

]]>