Java 200 times faster, almost as easy to use, so why Javascript ?

    Sep 01 2010 | 7:36 pm
    Since 5 years that I made these little efficiency tests (attached here), there have been many discussion on the forum about javascript vs java vs C, and the feeling that often comes out - false, i think - is illustrated by this Emmanuel Jourdan sentence :
    "JavaScript is slower than Java indeed, and Java is slower than C. That's in term of CPU/memory usage. In term of development time, it's about the inverse..." ( )
    CPU :
    Javascript execution is not only 3, 10 or 20 times slower than java, it IS between 200 times and 400 times slower than Java, in my test: In 4 millisec., my little test calculation loop is computed only 200 times in js, while 40000 times in java, on my MBP. (As probably every 'interpreted' code, max patchers execution is also around the same speed, 200 times slower than Java.) Now Java is about 1,5 slower than the C test (non-block-calculation), which, in most situations, is almost nothing. Ok for java, there is this JVM bridge little bottleneck every time that you cross an inlet/outlet, which is around 1 microsecond. Ok that's not always negligible, but well, when you make an mxj or javascript object, are making your loops inside it, so you're not supposed to [uzi] very fast over it... By crossing this JVM bridge the less often possible, for example by joining numbers into list before sending thru an inlet/outlet (which mean crossing this bridge only once) i'm then really peaceful with this bridge, since 5 years, and there's no point for me to go to C.
    Now, Development time :
    To me, if you use it to make some max objects the same way you would using Javascript, Java is as easy to learn. (It will only be more complex to learn if you want to go further thru "inheritance" concepts and stuff... to things you can't do with javascript.) Now, using the great Eclipse developing environment for Java - far better than the Java editor inside max - the development time should be - at least - AS FAST AS Javascript. The assisted editing make it even more convenient than javascript. Just the syntax is a little bit different from Javascript but it's not few more semicolons that are gonna slow you down. About C, beside its slower development time, a real pain is that, from what i understood, you have to restart max every time you modify your object. ( ) Not the case in java and javascript where you can refresh the max object.
    There's a great 'Step by Step Instructions tutorial' from Adam Murray, to use Eclipse with max: just a half an hour process, you're into java... So why Javascript ?
    I understand that the Javascript field is non-timing-sensitive stuff*, like UI related code, but in the beginning era of multi-touch - cf. - then even UI related routines are going to be called more and more often, then even for that, Javascript could bring signifiant slow down, compared to java, in the future.
    5 years ago, I remember a discussion with jkc saying he liked javascript, but 5 year after i'm still asking myself why.
    I don't get why so much maxers are using Javascript and C, while fewer are using Java. ( 2 times more messages on the Javascript forum than on the Java forum ) Perhaps it's just a lack of publicity ? i'm making it... :-)
    P.S : But there is again worst than javascript: look at the [coll] object efficiency in the 'test-on-arrays'...
    * in the WritingMaxExternalsInJava.pdf doc : "For timing sensitive events the js and jsui objects should not be used"

    • Sep 01 2010 | 8:13 pm
      "I don't get why so much maxers are using Javascript and C"
      C is still faster. '1.5 times' is not an absolute measure for everything... and it can make a big difference very fast in the development of larger apps.
      as for javascript, i'm not an expert and i do shy away from it(in Max) because i like C better, but it's the same argument as trying to say that you are happy to use Java even though you know C is faster. there's different situations suited for different things. there are situations where javascript does not take up much CPU at all. in those situations, the ease of quick scripting is applicable as an adequate substitute for lower-level programming.
      also, you develop C externals outside of Max, true, therefore you have to restart, but to me it's a negligible amount of time, when people talk of 'slower development time' for C, that's completely subjective: usually more true for those who are just plain slow at using their IDE and at programming in C.
      you make a good argument about javascript and java but your PPC compiling of C externals in your test while most are using intel these days and your arguments against C(while C is the cornerstone of how everything in Max was originally created), takes away from your argument by distracting it from the java/javascript relation alone and also may lead one to wonder why you've avoided the subject of C++ altogether.
      It is good to hear your passion for Java, though!
    • Sep 01 2010 | 8:29 pm
      I guess it really depends what you are trying to achieve.
      I have and do use all three. I don't think there is a good argument for only using one.
      If you (in many cases meaning me) are really serious about efficiency then C is probably the best way to go. 1.5x might be significant if you are writing audio code that is already expensive.
      Java has cross-platorm on it's side (that's the big plus for me).The garbage collection is a lot easier, but I'm not usually worried about cross-platform - I know the C API very well, and I can deal with garbage collection, so normally the speed wins out - when compatibility is a concern then java is normally my choice.
      Javascript is slow, but sometimes it's just the easiest. I use js a lot when I have an esoteric thing that I can't quite do in max, but the js API allows and I'm not going to want to reuse it a lot and speed is not a concern. Learning time for a language is not the only speed concern. I can write a quick routine in js in under 2 minutes and have it running. I doubt I could be as fast in java or C, even working from a template. THat is what development time means - not how long it takes for you to learn how to do it.
      The last thing which you fail to consider is the API available in each. One of the quirks of developing for max is that the APIs are all different. That means that sometimes it's really straightforward to do something in one, and not in another. Let's say I want to read a textfile without character limitations in. I did it in js in less than 20 lines. I don't think I've ever written an external in java or C that was anywhere near that compact.
      Great that you feel Java suits you, but each to his own. I can't help but think that when suitable, javascript is normally fastest to code, and often that is what counts.
      Just my take on it,
    • Sep 01 2010 | 9:18 pm
      Noob4Life, you are right about C efficiency can be better than '1.5 times' specially for block calculation (audio externals, jitter). Sorry I don't have the intel version compiled for the C test because it was made for me by a guy at ircam five years ago. I doubt the '1.5 times' would change a lot anyway.
      > AlexHarker : "I can write a quick routine in js in under 2 minutes > and have it running. I doubt I could be as fast in java, even working from a template.
      from a template, that's 3 minutes for Java...
      > One of the quirks of developing for max is that the APIs are all different.
      Considering the too limited time that C74 team have to develop the full max API for each language, i feel that pattr and UI support for Java, instead of Javascript, might have been the best choice, for a real-time-sound-and-image software where efficiency and timing is an eternal question.
    • Sep 01 2010 | 9:44 pm
      By the way. I'm not sure I believe your figures totally.
      Try the below. this would seem to indicate that js slightly less than twice as slow on my computer (around 2000 milliseconds plays 3300 ish). Bang the little button...
      Can you confirm your results and comment. I haven't had time to check your patch in detail but this is a simple tried and tested way of measuring speeds. I'm on intel so I didn't do the c compile...
      Assuming my figures are right (which they may not be) that would somewhat change everything no?
    • Sep 01 2010 | 10:02 pm
      My bad - I see now that you loop fois * 10 in the java code and fois / 10 in the js. Confusing but fair enough - that would account for the factor of 100.....
    • Sep 01 2010 | 10:10 pm
      Considering the too limited time that C74 team have to develop the full max API for each language, i feel that pattr and UI support for Java, instead of Javascript, might have been the best choice, for a real-time-sound-and-image software where efficiency and timing is an eternal question.
      ++ to mxj supporting pattr integration! Hoping it is coming soon.
    • Sep 01 2010 | 10:40 pm
      any use of javascript and java inside maxmsp should be illegal.
    • Sep 02 2010 | 8:11 am
      Yes AlexHarker, It was necessary to put this /10 for js and *10 for java and c, in order to avoid: 1- minutes to wait for the js to compute, 2- eventual bad precision over java an C if the test is too short. Then the compute time is corrected by multipling by this factor. (third [chrono] inlet in my patch). Sorry if my test then looks a bit complex.
      >> ++ to mxj supporting pattr integration! Hoping it is coming soon.
      Do you really think that could come soon? This would be nice. But looking at theses old topics ( and ), it doesn't look like coming soon.
      >> any use of javascript and java inside maxmsp should be illegal. What should be illegal is the use of patch cords for sequential and algorithmic stuff. Looking at other people algorithmic patches just give me headaches. What i made in Java would have cost 10 time more developing time using patch cords. Keep max for its best: Real time events, audio, UI.
    • Sep 02 2010 | 1:26 pm
      Yes - I guessed as much once I'd figured that out.
      I get about 160 times faster here on a dual 3.0GHz MBP.
      FWIW - the javascript calculations as far as I know are double precision - the java ones are not. I wouldn't want to speculate too much on what difference it would make, but I think you'd see it in the figures.
      Obviously, single precision in javascript is not an option, but it would be better to compare like with like as far as possible...
      I can't help but feel however, that you are looking at large data, large loops within loops situations that may not be typical uses of javascript. I'm not going to disagree that js is bad for this, but in small applications I think you might find that worrying about cpu usage is a waste of energy. After all - if you have a process that takes 1% of your processor (for example) in a scenario where you are running at around 67% - then when you speed that up by 200 times you simply won't see it clearly in the results - so it's not good economy. If it takes up 40% of your processor however....
    • Sep 02 2010 | 1:36 pm
      "Any use of javascript and java inside maxmsp should be illegal. "
      I've broken the law. rehabilitate me. someone! I've been trying to get started with C/Max for 5 years now. never got off the ground. Why? The thing I've had problems with in every language isn't the language part but the way it's set up on in the OS. There are never any details about it in any tutorial. There's always a line "find foo.baz.clib on your drive" and it's never there. I've spent four years programming mxj externals and I have no frick'n clue what ANT is, how to write scripts for it, or where "java" is on my drive. I open eclipse, include max.jar and I'm done.
      Maybe that makes me not a "real" programmer. I couldn't care less.
      I'll try again soon when I get around to installing snow leopard but setting up max and C has taken weeks of my life and I've never gotten it right.
      That comes off ranty.. but it's more a rant of desperation :-)
    • Sep 02 2010 | 2:14 pm
      I have used JS to develop two or three projects. As most of them were non -realtime I didn't care about efficiency. I chose JS essentially because I wanted to use the drawing capabilities of the JSUI object and because as a non-programmer (I mean no experience in any formal language outside Max, SuperCollider and GW-Basic). I also wanted the shortest possible learning curve.
      I had one project to create rhythmic patterns using JS. Reading the resulting data in real-time with JS produced tons of clicks while reading them from colls worked correcly (althought transition between Max4 and Max5 showed some reductions in performance for very fast MIDI rhythms).
      I have been thinking about learning C several times but I always postpone it.
      Just my 2 cents.
    • Sep 02 2010 | 5:29 pm
      > the javascript calculations as far as I know are double precision
      I even didn't know. in attachment is the version with double in java, which is 2 time slower, in fact. (good to know)
      I have a question: Is there anyone having a example patch that cannot be done using only floats precision ? (I've never used double, and whenever i use the Java.Math methods i immediately convert in float.)
    • Sep 02 2010 | 5:56 pm
      > but in small applications I think you might find that worrying about cpu usage is a waste of energy.
      The problem with small applications, is that they often get bigger, or that one day you need to load a bunch of them for a live or something, and then nothing is working as before and you don't know why.
      If we were talking about a factor of 1,5 or 2, then ok, worrying about cpu usage for that may be a waste of time for a small application. But we are talking about a factor which is between 100 and 400 (yes, 400, see my 'Efficiency-test-on-arrays.pat': the loop is computed only 1000 times in js, while 400000 times in java, on my MBP.) Compared with java, to me, javascript is mostly a waste of energy for the computer.
      ...Ecologists would even make javascript illegal, what about your computer carbon footprint? :-D
    • Sep 02 2010 | 6:25 pm
      If MaxforLive already included LiveAPI integration for Java, I'd be on the bandwagon...for now I'll code it in js and convert it when it needs done.
      (actually, I guess it makes little difference since the LiveAPI is low-priority anyway)...
      Still...the link to the tutorial above is helpfull...I've already installed Eclipse and started reading about Java. There are several things I wrote in js before I had to convert them into pureMax because js was too slow. I'd much rather have them in a script language....editing algorithmic stuff in Max is like trying to popular music trends....
    • Sep 02 2010 | 6:34 pm
      Double precision is a real necessity in certain scenarios - for instance:
      phasor accumulation (for audio rate buffer playback for example) calculating certain filter coefficients accurately
      My personal experience of double precision critical situations is more in the domain of audio rate programming admittedly, but that is just me. You seem to be suggesting that doubles are unnecessary. I'm trying to suggest that everyone's needs are different, and if java is twice as slow with doubles (that is inline with what I expected) - then on my computer you are looking at closer to 75 - 80 times slower for js doing the same thing - which is a substantially different figure to 200. Sometimes the speed gains offered by C *really* matter to me, whereas to you it isn't worth it.
      As for arrays - sure - I didn't say it was fast, or good for that. However, in the event that you do very little in a function call and you make the function call lets say every 10ms (which is really quite often compared to a message-based musical timing) - the CPU you might be talking about is really not worth worrying about.
      Believe me II have spent many hours optimising cpu and memory usage - to the point of ridiculous obsession. I understand the drive, but rule 1 of optimisation is don't optimise. It has many disadvantages. Rule 2 is optimise what matters first. Let's take Chris Muir's simple FM patch from a recent thread. Turns out that mtof~ accounts for over 50% of the cpu that that patch consumes. I can spend all the time I want optimising other parts, but some of them are so negligible that I could put in hours and hours and never see any real gain. I replaced mtof~ with a more efficient alternative and the patch ran almost twice as fast (55% with 32 voices down to 28%)...
      Often I am using js for one off calculations / loading processes / things that happen maybe less than once a minute. Unless those operations are noticeable intensive then optimisation is not a concern.
    • Sep 02 2010 | 6:50 pm
      Alex wrote, "Often I am using js for one off calculations / loading processes / things that happen maybe less than once a minute. Unless those operations are noticeable intensive then optimisation is not a concern."
      ya, this is what i was trying to say... for such contexts, a quick scripting language(like JS/Python/etc.) seems better than any small efficiency gains you get from a lower-level language.
    • Sep 02 2010 | 7:03 pm
      Oh please, the days of low-level languages for general purpose programming is over (should be anyway).
      Using C as an application language was never a good idea and still isn't. It was designed for system programming, and that is were low-level concepts such as direct access to memory should stay. The programming platforms of the future are probably going to be virtual machines supporting dynamic linking, JIT-compilation (which already beat AOT-compilers in speed) and garbage collection on the fly.
      One reason to use JavaScript over Java is that it is a functional and more expressive language. Another is that is has direct access to the Max scheduler and object system, which Java has not. If speed is an issue, you can switch to Rhino and compile it to JVM bytecode, which will execute at java speed (this would of course restrict you to the Java API).
    • Sep 02 2010 | 8:03 pm
      Hans Hoglund wrote: "Using C as an application language was never a good idea and still isn't." I think everytime people bring C into the debate between Java and Javascript, it's going to distract from credibility on other points(JMax is dead, btw). I agree with most of what you say, but this holds no water whatsoever considering we are all here because of an application called "Max" which was(and to a great extent still is) written in C.
    • Sep 02 2010 | 8:45 pm
      @Noob4Life I have no problem using and relying on stable software. What concerns me is that the performance arguments is used to hold back the emancipation of new and better languages. I think it should be the other way around, we should look out for more expressive ways to program and then consider implementation.
      Of course Max was designed to connect C programs, that was the the accepted way to do real-time back then. Now we have other options, there are hundreds of languages with safe memory, lambdas and dynamic dispatch that are fast enough for real-time, many of which can be integrated in Max.
    • Sep 02 2010 | 10:15 pm
      "I think it should be the other way around, we should look out for more expressive ways to program and then consider implementation."
      well put! after all, all 'languages' serve the primary purpose of communicating and disseminating any form of information(efficiency concerns are not always paramount to communication). if we talk of the future, i believe all apps and data will be web-based eventually, and personal comps will only be a terminal to that network, this will actually be more affordable and will provide better access to information for even 3rd world countries... sounds dangerous to comprehend at first, but since i don't think google/verizon/microsoft will ever succeed in completely limiting/commodifying our access and presence on the web, it's very possible... therefore, i agree with all your statements of what options we have and will have.
    • Sep 02 2010 | 10:48 pm
      I have never really understood why people want to do time critical operations with Java. As a software developer designing a real-time system, the last thing I want to build into it are unknowns like garbage collection and byte interpreted instructions. That just adds unknown inefficiencies that keeps you from squeezing all the power you can out of your system.
      Max is an open architecture that allows you to insert your own objects in that audio and data signal path. It is supposed to be as efficient as possible. Implementing your algorithm in C is probably the best compromise between readability and effecienncy.
      But for doing UI stuff I think javascript is decent. Although I think python is a much better language. I hope that one day, Cycling74 will add native support for it. I would love to have access to SciPy in Max!
    • Sep 03 2010 | 1:07 am
      "python is a much better language. I hope that one day, Cycling74 will add native support" +1 4 Python!
    • Sep 03 2010 | 1:15 am
      @Anthony Your arguments are just not valid. The JVM of 1990s were slow, modern implementations are not. GC and JIT are not "dumb overheads" but higly intricate compilation techniques that may actually yield better performance than a C compiler. That JVM's are slow is just a plain old myth.
      What Java has is a slow startup time (about 500 ms on my machine, and this happens once when you load your first Java class). This is not because of JIT, but because Java links everything dynamically. The benefits of this are so huge that I have no problems with a split-second startup delay.
      Furthermore I would argue that in a real-time application stability is more important than raw performance. In Java code you will never have a memory error except if you mess up concurrency. Use Clojure and you will not even have that.
    • Sep 03 2010 | 1:19 am
      Also, why should we need to compromise readability to have efficiency? Why not use a language that has both? (Not that Java does).
    • Sep 03 2010 | 8:09 am
      >> Why not use a language that has both? Good question.
      >> But for doing UI stuff I think javascript is decent.
      Try ej.fonction.js from the ejies, put lot's of segments and manipulate the visualizations, then javascript is not decent anymore...
      >> readability
      Comparing a javascript code with the same thing done in java, to me, in general, that's nearly the same in term of readability. The situations were javascript really looks more "expressive", are not coming so often to me, looking at codes. (plus, the really nice way that Eclipse manage color for instruction types and highlight other variables when you type on one, makes java even more readable, in my personal experience.)
    • Sep 03 2010 | 11:20 am
      "I would argue that in a real-time application stability is more important than raw performance. In Java code you will never have a memory error except if you mess up concurrency. Use Clojure and you will not even have that."
      You obviously know your stuff, and I respect your opinion, but this argument at least is void if the programmer deals with memory allocation and access correctly. Also, as always YMMV with regards to the importance of raw performance. As we are dealing with a real time audio language here, and portable computer power is not infinite, I think it is clearly arguable that in some scenarios available processing power limits what is desirable, and therefore raw performance is highly relevant. In time critical situations 20% (as quoted in the linked article) slower may simply be unacceptable.
      In reality I simply don't believe that 20% is a typical figure for what is being discussed here (max external in java vs one in C). I'd be happy to be proved wrong, but I'll be sticking to C for efficient audio processing until then.
      Don't get me wrong, I'm not arguing against the use of java, I'm just think that any choice of language is based on a combination of factors, and there are clearly arguments in all directions - using the most appropriate language in the circumstances seems would be my approach, and for me that could result in using C, java or javascript.
    • Sep 03 2010 | 2:10 pm
      Me, I'm not arguing against the use of C, but let's feed these interesting debates : About C vs java, in the C74 WritingMaxExternalsInJava.pdf doc, page 43, from Topher La Fata :
      "A properly written Java signal processing external is typically about 1.5-2.5X slower than the equivalent external written in C. A lot of this depends on what sort of processing your external is doing. In most cases the more computationally expensive your external, the closer that the Java and C versions will be in performance. This is because the biggest overhead introduced by doing your signal processing in Java is in the context switching that occurs when the mxj~ bridge calls from C into your Java signal processing routine. The cost of this context switch is amortized across the amount of time you spend actually accomplishing your task, so the more expensive your task, the less relatively expensive is the cost of the context switch."
    • Sep 03 2010 | 2:36 pm
      "Me, I'm not arguing against the use of C," but then you go on to do just that. At least be truthful rather than hypocritical. (Also, the quote starts with the wording "typically" and "depends on what sort of processing your external is doing", so it's not an empirical statement whatsoever.)
      I think what everyone is doing here is only proving that developers are extremely high-maintenance people ;) The discussion is whittling into something uninteresting and convincing me to stay away from Java(since devs in that environ seem more desperate to talk sh!t about all others more than anyone else i've seen). What you've convinced me of, is that even though you don't think it's significant, C is still significantly faster than Java(because 1.5-2.5xfaster can make a very big cumulative difference to me).
    • Sep 03 2010 | 3:05 pm
      With all due respect Hans, I definitely see the merit of your argument. Java VM technology has certainly advanced in the last 10 years.
      But I feel a lot of these benchmarks people quote are perfect scenarios that don't really reflect the real time performance environemnt of an integrated system (memory latency, kernel i/o, graphics/audio interfaces). You can argue all you want about how some JVM does an FFT faster than C, but put it in a real world environment and I think you'll see different results.
      Arguable the most complex real-time audio/graphics system out there are console game systems like the PS3 and Xbox. Why hasn't Sony or nVidia, chosen Java as their development language/environment of choice? Because it is an inefficient language for that environment. Having done video game development for 7 years now, I know for a fact the tremendous work that goes into squeezing every drop of processing power out of these systems. You are interfaceing with DSPs, GPUS, pixel/vertex shaders, etc. Implementing things in Java would be a joke, I mean really.
      Why would I not want my Max patch to perform at the same level?
    • Sep 03 2010 | 5:31 pm
      Whatever happened to testability? in java, in javascript, and MAX MSP? Why don't we do comparisons to settle this please? This whole thread confuses me!
    • Sep 03 2010 | 7:22 pm
      > "and MAX MSP?" From what i remember when looked at it, i think Max-Msp execution speed is more or less the same than javascript execution speed. (or something between 0.5X-2X)
      To make it clear: I am NOT arguing anything against C. I just mean that to write externals, Java is almost as great - and really more simple to use in my personal point of view - in most of the situations that i encounter. Sorry, I would add 3 words to this sentence from my first post, which some can find provocative, if i could : "Now Java is about 1,5 slower than the C test (non-block-calculation), which, FOR MY PURPOSE, in most situations, is almost nothing." C is great, Java is great, Max is great, MMF for Ipad is super Great!, and we are all great people!
    • Sep 03 2010 | 7:24 pm
      I was just screwing around :-)
    • Sep 03 2010 | 9:22 pm
      "I was just screwing around :-)" no one blames you, either, it's getting hard to take this thread seriously.
    • Sep 04 2010 | 3:10 pm
      Implementing things in Java would be a joke, I mean really.
      I think this is still the old prejudice, but no matter. Performance of JVM for critical tasks has and will countinue to be widely debated. Of course Max is fundamentlly a native environment and integration with any VM can never be entirely smooth.
      I always figured the main reason for JavaScript in Max was there to provide a more lightweight interface to patcher scripting.
    • Sep 04 2010 | 11:38 pm
      Wow, a well timed article considering I've been thinking about this over the past few days. If I could add a little bit of a hypothetical situation though...
      It seems that we now have a lot of work being done on JavaScript engines, with the likes of Google's V8, Apple's Nitro and Mozilla's JägerMonkey. If one of these was implemented into Max, would there be enough of a performance gain to put it anywhere near level with Java? As I understand it, these new engines are starting to compile directly to bytecode rather than just interpreting.
    • Sep 07 2010 | 2:50 pm
      @DiGiTaLFX Agreed, there are many promising new implementations. Personally i use Mozilla's Rhino and compile to JVM bytecode which runs like lightning. I am not doing real-time audio in it though ;).
    • Sep 08 2010 | 7:54 am
      @Hans I've been checking this much Java do you need to know to work in this manner? I am also not doing RT audio, but I need faster processing for arrays and such...I'd like to start working on some flocking/algorithmic stuff and the last time I did this sort of thing in js I ended up having to rewrite the whole routine in pure Max b/c it was just too slow...I'm thinking this might be a nice alternative, without having to spend the extra time on the front end learning a new language.
    • Sep 08 2010 | 8:12 am
      > " the extra time on the front end learning a new language."
      Does this look that much more complicated ?
    • Sep 08 2010 | 8:54 am
      It definitely is Alexandre. For you it's not because you're used to it. If you look at the same thing in C, you could have the same conclusion, it's not really much more complicated, as long as you have the skill, time… That's the reason why there's the 3 approaches, they are not equivalent in term of performance, nor in term of knowledge required, development time, cross/platform... Just use the language you know, and if that's not fast enough switch to the next one ;-)
    • Sep 08 2010 | 1:45 pm
      @alexandre agreed! Do you have the same code in C? I'd love to see a side by side comparison of all three languages.
    • Sep 08 2010 | 3:07 pm
      The code in C, "calcultest.c", is in the "" attached above, in the first post of this topic, although i think that it could really be shorter (not made by me - i don't use C - but by Diemo from Ircam 5 years ago).
      Also, Emmanuel is right that this js/java example above is a bit too simple. There ARE more differences between coding in Javascript and Java that are not shown here. I just posted it to show you that java is not so complicated. Like I say on my first message, and like AudioMatt meant, i think : To just use java for mxj externals, it's ok if you have a light knowledge* of its structure. (Inheritances,polymorphism,etc... After few years of using java for mxj externals, i'm just starting on theses concept now, but that's because my mxj externals start to have thousands of line of code..)
      And i doubt about what Emmanuel say about development time, that Java would be slower to code than Javascript: Can someone organize a big Java/Javascript coding competition and see the result ? :-) I'm wondering that if javascript is faster to code, that from really short... ...For an execution speed lost of a factor which is between 60 -to AlexHarker POV - and 400.
      * But you do need to learn a bit about some java stuff: primitive types, operators, cast, arrays and Java.Math class if need some math. This is 10% of my java learning book.
    • Sep 08 2010 | 5:03 pm
      If it's difficult to imagine what *60 or *400 really mean, have a look at my modified version of Flies.maxhelp attached.
      Anything like this in a js object is, from far, impossible.
    • Sep 08 2010 | 7:40 pm
      Nope...that doesn't look that much more complicated....but I'm guessing that everything I would normally do in js isn't going to translate quite as easily. I've gotten used to the way js types variables, and I know how its integration with Max works. Besides: a lot of the stuff I need to do, I've already written scripts in js for the routines. Being able to convert already written scripts fairly easily with something like Rhino sounds very convenient.
      I will learn Java...its merely a matter of when I will have the time. I'm also trying to tackle Python right now (and I have a more immediate need for it), which is all that much more confounded by the lack of a decent way to test in Live (I'm working on control_surface scripts). Plus, it goes back to my original post: since the majority of my work is with the Live API at present, there is no facility for accessing those objects directly with Java, nor any speed increase since the API can only be accessed low-priority.
    • Sep 10 2010 | 4:37 pm
      FWIW, we are looking into having a much faster JS engine for the next major version of Max. Java, JavaScript, Python, Lua, and C are all great languages, each with their advantages and disadvantages. If we could easily support everything in all languages we would, but we have to balance our development and maintenance priorities.
    • Sep 10 2010 | 10:31 pm
      That's worth quite a bit (but of course a bird in the hand is worth two in the bush)....
    • Sep 11 2010 | 10:58 pm
      @Joshua Yay!!! :D
    • Sep 12 2010 | 8:17 pm
      @Joshua Kit Clayton
      a thousand times yes. v8 with commonsjs modules support please :D ?
    • Sep 13 2010 | 7:11 pm
      Probably not V8, since it doesn't support multithreading, and would require a complete rewrite of much of our code. Jaegermonkey is the one we're watching. Lets of great work happening there, and it's coming close to Nitro/V8 performance.
    • Oct 21 2010 | 10:16 pm
      Nice discussion, very enlightening to hear such interesting opinions. For me java provides the big advantage of the possibility of reusing code and the access to very interesting libraries, such as those coming from Processing. I would love to see a more supported class-oriented approach on the SDK. Besides efficiency it is interesting to think what kind of new technology can be implemented or bridged inside max(i am thinking of openCL or the quartz technologies, for instance).
    • Nov 03 2011 | 7:55 pm
      So now that Max 6 is out, I decided to run these tests again and see what the difference in performance of the JavaScript engine was. I get around 250 iterations in Max 5 and 650 iterations in Max 6. So that's a 2.5 times increase in performance! It's still way off of the ~27000 iterations I get from the Java VM (double) though...
      Would be interested to see if someone could port the test to object.
    • Nov 04 2011 | 8:14 pm
      mmmmmm :) That's good news, I'd love to hear some further confirmation of this....I've started doing stuff that needs to be fast in Java, but I still prefer the ease of js, and use it whenever possible.
      On the other hand, how much of the stuff that I reserve for Java (for speed) will be possible with ~gen now, I wonder?
    • Nov 11 2011 | 6:05 pm
      Just a quick comment and examples. Hopefully to illustrate some best practices in JS for improved performance.
      These JS files you've provided make heavy use of global variables, and even then ones which haven't been scoped with var, The former are slow, and the latter are even slower (and dangerous since they are values shared between instances).
      This is true for both the older spidermonkey JS implementation, as well as the new JIT compiled Jaegermonkey implementation. And in the new engine it's even more important for optimal JIT performance.
      I've taken a brief moment to revise your examples just comparing your JS with some improved JS files.
      Also, some of your examples had codepaths which could possibly be eliminated (e.g. a large loop which sets one variable over and over again, so in effect the only one necessary to set is the final loop value, or if those values are never used in the future, they don't need to be set at all). So they might not be accurate tests of read/write performance, but rather a test of deadcode elimination. I didn't have time to investigate whether or not this is the case.
      Finally, also when testing you need to execute a function a few times before JS will completely JIT compile, so be sure to execute a few times to get the optimum JIT compiled benchmark.
      That said, Java will be faster than JS. No question. I don't know of any of the new JS implementation which are as fast as the JIT compiled Java VM. Part of this is because of static typing and other language features.
      Javascript, however, gains all that nice small talky dynamic typing and binding goodness, and is in many ways more agile than programming in Java, as long as you don't trip yourself up in the many errors that can happen with dynamic binding when not carefully coded.
      Anyway, not trying to get into any language better than another conversation. While I personally mostly code in C, I'm language agnostic. Each language is great for its own reason.
      My results with your examples are below:
      Calculations test:
      Max 5: old global js:349 revised js:459
      Max 6: old global js: 913 revised js: 11875 (~13x speedup)
      Array Fill Test:
      Max 5: old global js:0.53 seconds revised js:0.33 seconds
      Max 6: old global js: 0.33 seconds revised js: 0.06 seconds (~5x speedup)
      Array Writing Test:
      Max 5: old global js:1658 revised js:3041
      Max 6: old global js: 2240 revised js: 6207 (~3x speedup)
      Array Reading Test:
      Max 5: old global js:1249 revised js:3325
      Max 6: old global js: 1684 revised js: 9278 (~5.5x speedup)
    • Jan 10 2012 | 12:46 pm
      Thanks Joshua for those tips! It makes sense that the assumption that the most efficient way of doing something in one language would be the same in another is actually wrong now that I think about it!
    • Mar 31 2012 | 5:17 pm
      So I decided to try run the calculations test in for a comparison there too. I've ported Joshua's revised js test to lua (as I believe lua likes local variables too) and have attached to the post.
      I was quite surprised that the result was less than half as fast as js in Max 6 :(
    • Mar 31 2012 | 5:56 pm
      This doesn't surprise me too much. The JS object in Max6 is using a JIT compiler, which are good at optimizing math in tight loops. is using the stock Lua interpreter, which isn't JIT compiled. If JS was still using a non-JIT compiler, would be faster.
      There is a LuaJIT project, which is blazingly fast, particularly for these kinds of tests. If was using that, it would be as fast if not faster than JS in Max6. I'll add a feature request for LuaJIT.
    • Mar 31 2012 | 6:36 pm
      Ooooo, that wasn't the response I was expecting! LuaJIT would be absolutely amazing :D
      Thanks for explaining the differences :)
    • Aug 20 2012 | 4:26 pm
      Hi, I felt it's been a long time since i didn't complain about javascript :-) It seems to me that javascript object in max6 are about 10 times slower to load than in max5...
      It's less than a second to reload 200 objects of my .js in Max5, and between 5 and 10 seconds (sometimes 15) in max6. ...which probably means sometimes 80 milliseconds to load one single .js! Try the simple patch below in max5, then in max6: There are 200 little abstractions each containing a very simple js object: 1 - delete them all, 2 - then do command-z...
      We are redesigning simpler our modular instrument structure in java and max (with full automation, powerful presets and sequencing system*), and each of our hundreds of parameters are connected to a little abstraction to connect numberboxes and sliders to a main java mxj object**. We need to built a dynamic "path" for send and receive objects and java would have been fine and super fast for that, but unfortunately, in java we can't access to the "maxbox" containing the patcher :-| So we though about using javascript for that but that max6 reload slowness doesn't sounds good. So we finally wrote a c-external for our little abstractions to access to this "maxbox" stuff, which will be fine.
      ** I though about using pattr, but we prefer our "little-abstractions" system for several little reasons, two of them being that you cannot directly dump value changes in one place from hundreds of scripting-named objects without also writing a c-external for that, and that pattr have the reputation to be slower that [send] and [receive].
    • Aug 23 2012 | 12:48 pm
      Hey- I posted this on another thread, but I think its appropriate here:
      Do you know if anyone has given any thought to implementing Google's v8 interpreter? Seems like its 8-10x as fast as spidermonkey. How hard would it be to make an external that references and autowatches a js file or an mxj with something like jav8?