On Tue, Sep 7, 2010 at 1:13 PM, Daniel ***** <****> wrote:
Any idea why it takes so long (~30s, see below)?
Oh yes man !
But before all, pardon me to put this reply on my blog, for all the script users to know that (as a consequence, i’ve added the email@example.com mail to the « To » field. So don’t reply to all, unless you want our private discussion to become totally public ;-)).
And if I’m too beginner for you, or too hard core, aprdon me again, as I’m quite bad at teaching anything.
Unfortunatly, if coding using Groovy is damn fast, executing Groovy code, especially using some of the options I use, is waaaaaay slower than quite anything else. Le me detail them for you.
First of all, Groovy code is run in the Java VM, and before to load even the first element of my script, the Groovy execution environment has to load. Since the ten years I start coding in Java, this language has always been recognized for the completeness of its standard library, its ability to run everywhere (thanks to Sun work), and its damn slow startup time. Obviously, when using an interpreted language like groovy, there is no way for the default startup time to fasten, as the posterous class needs to be parsed, and interpreted as executable code.
Once the code is loaded in the Java Virtual Machine, some of the dependencies I use have to be resolved (namely nekohtml and groovy http-builder).
Resolving dependencies is usually an enterprise thing, made by heavy metal tools like maven. I use that too often in Java code for going this path in my Groovy code (and Groovy is too agile for that). Instead, I preferred the Groovy way by using Groovy grapes, which resolves dependencies at runtime. yes, at runtime, at the very moment you choose to run the script. As a consequence, once the script is loaded, each time it encounters one dependency declaration, it stops, the time to verify that your ~/.groovy/grapes folder well contains the required dependency, and the time to add the jar to your classpath. which, again, is quite slow.
Finally, in order for you to enter your arguments with ease, I use a CLI parser (provided as default by groovy). This, obviously, takes some time.
And once all that job’s done, you can see that unfortunate execution time :
$ time Desktop/groovy-1.7.4/bin/groovy posterous.groovyThis is posterous export script v 0.6You like that script ? You already use flattr ? Please go to http://flattr.com/thing/54243/Posterous-backup-script to show your appreciationerror: Missing required options: u, p, ousage: groovy posterous.groovy -u email@posterous -p password -ooutputFolder-d,–downloadThumbnails When present, thumbnails as well as normal sizeimages are downloaded. This option is byrequest of Eli Weinberg, with my best wishes.-h,–help provides full help and usage information-o,–output <arg> An eventually existing output folder, where alldata will be output. Beware, if some dataexists in that folder, it may be overwritten.-p,–password <arg> Unfortunatly one have to give its password tothis little script-s,–separeMedia Separates media from posts directory. When set,all medias are copied in subfolders of outputfolders named as posts they’re associated with.This option is by request of Eli Weinberg, withmy best wishes.-u,–username <arg> Sets posterous mail address here-x,–xsl <arg> Gives an XSL stylmesheet URL that will be putin all generated files
Now all is say, some questions arise :
- can I make my code faster ? for which the easy reply is : YES, definitely. there are at least three obvious improvements ways : translate the code into Java, use static dependencies, and improvded command-line parsing (obviously, going to Java code will imply the two others, due to classical performances figures)
- will I make my code faster ? for which my definitive (unfortunatly) reply is NO. Going the performance way is obviously an interesting intellectual challenge, but I’ve already solved it many times and, believe me, it’s not that interesting when done for the tenth time. Furthermore, I don’t think backing up a posterous account needs to be faster than light. As a consequence, even if I perfectly understand that you’re someway concerned about that script slowlyness, I won’t make it faster by performing all those modifications
There is in fact an other reason. This script currently is only 13 Kb. Creating an equivalent Java application and packaging it would consume hundred Kb. Of course, you download nekohtml and groovy http builder. But you downlod them only once, even if script is updated. As a consequence, i consider it a valid trade between feature and weight.
Pardon me if my language may seem a little rough for the above sentences, as I’m absolutely not trying to bully you. In fact, each time one of posterous backup script users sends me a mail, I consider myself happy as these discussions allow me (like in this very case) to clarify some points that may not be clear. In other words, thank you for asking that question. I hope my reply was clear enough. If you have any question, remark, love declaration (I write that just for my usual blog readers, Daniel), don’t hesitate, i will be more than happy to reply.
Thanks again for that question.