Demis, It's the opposite: Py's data access is slower than Java's, at least according to Darshan's experiments:
http://groups.google.com/group/google-appengine/t/7a8b716ecc8d5bb5 see also the reply in stackoverflow: http://stackoverflow.com/questions/3886341/is-appengine-python-datastore-query-much-3x-slower-than-java (btw, the api ms are exactly the same, suggesting he's doing the same in both implementations) In general, it makes imho more sense to use server side tools that save resources (which also run faster, by coincidence), so I'd rather like to see a C++ sandbox on GAE than Java script. Furthermore, if you like to have a homogeneous environment on client and server, have a look at GWT. Ok, its Java instead of js, but for us it works very well. Maybe J's API is very extensive (I'd rather not say bloated), but mostly not in the sense of more overhead, but more choice on the menu. Nobody urges you to use all of it, but there are some nice gems around in the Java community. Cheers, R. On 11 Okt., 23:24, Demis Bellot <[email protected]> wrote: > Cool, though Ringojs is no Expressjs and ultimately if I'm not mistaken all > calls will eventually goes through Java's Sync IO and standardized API's no? > > I'm not sure why Java data access is slower than Pythons > (http://gaejava.appspot.com/) but I'm guessing this probably has to do > needing to provide adapter implementations to Java's standard interfaces? > > I never liked adding layers of abstraction on top of already bloated API's > and this would be a chance for a fresh start with no backward compatibility > requirements and existing APIs to adhere to. I'm sure all the BigData access > is async underneath no? And we know Memcached screams in Async/UDP mode! > (http://www.facebook.com/note.php?note_id=39391378919) > > - Demis > > On Mon, Oct 11, 2010 at 10:00 PM, gabriel munteanu <[email protected]>wrote: > > > > > guys, thanks to java gae, we already have javascript on appspot > > checkout ringojs , a ~commonjs framework. > > or you can go to a much lower level through rhino itself. > > > cheers > > > On Mon, Oct 11, 2010 at 11:38 PM, nickmilon <[email protected]> wrote: > > > I think a new language should be out of the question, well until > > > current platform is stabilized. > > > But .... > > > then again who am I to tell big G what to do and what not. > > > ;-) > > > > On Oct 11, 10:06 pm, "Ikai Lan (Google)" > > > <[email protected]<ikai.l%[email protected]> > > > > wrote: > > >> Believe it or not, we've talked about this. There's a lot of interest in > > V8 > > >> and JavaScript. From a technical standpoint, there are still advances > > that > > >> need to be made in V8 (garbage collection comes to mind) - see for > > yourself > > >> by searching for articles about Node.js and GC. > > > >> Ultimately, it comes down to resources, which is probably why we aren't > > >> working on this right away. It makes more sense for us to harden our > > Java > > >> and Python runtimes, allow more classes into the whitelist, and look > > into > > >> ways we can support versions of Python that are higher than 2.5. As much > > >> traction as Node.js has in the blogosphere and Hacker News, it's still > > hard > > >> to make a business case for a platform that has, at best, poor tooling > > and a > > >> small (albeit enthusiastic) core community. You have a gripe with Python > > >> being slow - I'm surprised this is an issue, as most of your time is > > spent > > >> blocking on RPC calls, not interpreter gotchas. It doesn't matter how > > fast > > >> your Ferrari is if there are stop signs on every block. > > > >> I'd look into Heroku's experimental node.js support: > > > >>http://blog.heroku.com/archives/2010/4/28/node_js_support_experimental/ > > > >> Try building an application using node.js as your full application > > stack. > > >> I'd love to see more article content about the challenges/benefits of > > doing > > >> this. There isn't enough, as far as I am concerned. > > > >> -- > > >> Ikai Lan > > >> Developer Programs Engineer, Google App Engine > > >> Blogger:http://googleappengine.blogspot.com > > >> Reddit:http://www.reddit.com/r/appengine > > >> Twitter:http://twitter.com/app_engine > > > >> On Sun, Oct 10, 2010 at 8:46 PM, John McLaughlin < > > > >> [email protected]> wrote: > > >> > Thanks for the info Demis, I alway like listening to Douglas > > >> > Crockford. I also checked out > > >> >http://developer.yahoo.com/yui/theater/video.php?v=glass-node. > > >> > Very interesting stuff, I can definitely see using it in the future. > > >> > In particular using JavaScript as the templating engine seems really > > >> > powerful. So you've changed my mind. However since I'm still worried > > >> > about the "plethora" part of "...plethora of well-tested JavaScript > > >> > frameworks and libraries available...", I'll say that if node.js, > > >> > YUI3, and JSLint are defined as best practices -- I'm on board -- > > >> > server-side JavaScript all the way. > > > >> > - John > > > >> > On Oct 10, 4:21 pm, Demis Bellot <[email protected]> wrote: > > >> > > Unless I'm mistaken about recent advancements, Python belongs in the > > same > > >> > > performance category as Ruby, Perl and PHP i.e. slow compared > > against > > >> > native > > >> > > or optimized managed languages. > > > >> > > I understand there are a number efforts underway to improve > > performance > > >> > > (e.g. using an LLVM backend withhttp:// > > >> > code.google.com/p/unladen-swallow/), > > >> > > but I don't think this is actually being used yet? > > >> > > I'm sure with having Guido onboard Python has been heavily optimized > > for > > >> > GAE > > >> > > but there is only so much optimizations possible with CPython. The > > >> > library > > >> > > code may be fast (i.e. thin wrappers over C libs) but the users code > > is > > >> > > going to be interpreted and slow. > > > >> > > Since it impacts the performance of Chrome (one of Google's most > > valuable > > >> > > assets) and its millions of end users, I would think that more of > > >> > Google's > > >> > > engineering effort is behind making JavaScript as fast as possible > > with > > >> > V8 > > >> > > which I believe shows in the computer language shoot-out benchmarks, > > >> > where > > >> > > it looks as if V8 is several times faster than any Python > > implementation > > >> > > available: > > >> >http://shootout.alioth.debian.org/u32/which-programming-languages-are. > > .. > > > >> > > The GAE Python API's also exposes sync IO requests and encourages > > >> > buffering > > >> > > which I believe also contributes a significant performance penalty > > per > > >> > > request. > > >> > > This is only an educated guess and I'm not sure what these raw > > language > > >> > > numbers translates in GAE performance though it should be pretty > > >> > indicative > > >> > > of the perf advantages possible. With the lack of an actual V8 > > >> > > implementation, internal Google Engineers would have the best > > insight as > > >> > to > > >> > > the potential gains if any (which I encourage on this thread). > > > >> > > As for the language impedance mismatch, I think that having code > > from the > > >> > > same application being able to run on both client and server is > > heavily > > >> > > underrated. > > >> > > YUI is show casing some exciting possibilities they're doing around > > >> > node.js > > >> > > today: > >http://www.slideshare.net/apmoore/running-yui-3-on-nodejs-bayjax > > > >> > > Where currently a lot of their JavaScript libraries already run on > > >> > node.js, > > >> > > but even more impressive than that they have implemented a > > server-side > > >> > W3C > > >> > > DOM that enables the same code they use do generate their DHTML > > Calendar > > >> > > control can be run on the server and output rendered on clients that > > have > > >> > > JavaScript disabled. Much of Google's Closure Library and its > > optimized > > >> > > JavaScript compiler should be able re-used on the server as well. > > > >> > > I think this is only touching the ice berg, and Douglas Crockford > > has an > > >> > > inspirational video presentation on using JavaScript and an > > event-loop > > >> > > architecture (like node.js) on the server: > > >> >http://developer.yahoo.com/yui/theater/video.php?v=crockford-loopage > > > >> > > Before V8 and node.js I would not have considered it, however with > > the > > >> > > maturing of these technologies, the plethora of well-tested > > JavaScript > > >> > > frameworks and libraries available and what I believe is a > > rejuvenated > > >> > look > > >> > > back into JavaScript - I think there has never been a better time to > > >> > provide > > >> > > a server-side JavaScript option in GAE. > > > >> > > - Demis > > > >> > > On Sun, Oct 10, 2010 at 11:10 PM, John McLaughlin < > > > >> > > [email protected]> wrote: > > >> > > > My gut reaction to this is that I'd rather have Python 3 over > > server > > >> > > > side JavaScript. The Python API is already comparable to (and > > >> > > > possibly faster than) the Java API. Seehttp:// > > gaejava.appspot.com/ > > >> > > > and > > >http://stackoverflow.com/questions/1085898/choosing-java-vs-python-on. > > >> > .. > > >> > > > . > > >> > > > So the performance argument is arguable at best. Additionally I > > don't > > >> > > > think the value of a tight developer community can be > > underestimated. > > >> > > > In particular I find these forums to be a huge benefit for > > learning > > >> > > > best practices, tips, and tricks. But I fear that introducing > > another > > >> > > > language -- and especially JavaScript, with it's tower of babel of > > >> > > > libraries and coding styles -- would decrease the signal to noise > > >> > > > ratio of the forums and the developer community. And that would > > >> > > > affect my productivity more than "language impedance". > > > >> > > > Don't get me wrong -- I really, really, like JavaScript. It's an > > >> > > > awesomely creative language for making highly functional user > > >> > > > interfaces. But I really, really like Python as well -- mostly > > >> > > > because it is so clear, readable, predictable, and mostly has only > > one > > >> > > > right way to do things. This seems like a better language choice > > for > > >> > > > server. At least until GO (http://golang.org/) catches on ;-) > > > >> > > > John > > > >> > > > On Oct 10, 1:16 pm, Demis Bellot <[email protected]> wrote: > > >> > > > > Thanks for the link, I just added a little excerpt from my post > > to > > >> > the > > >> > > > list. > > > >> > > > > I think the fact that so many other devs are coming to the same > > >> > > > conclusion > > >> > > > > independently speaks of how favourable a JavaScript for GAE > > solution > > >> > is. > > > >> > > > > I'm sure if Google released a poll to gauge public interest > > about it, > > >> > you > > >> > > > > would get an positive response from the dev community. > > > >> > > > > Here's hoping for some positive steps in exploring the idea. > > > >> > > > > - Demis > > > >> > > > > On Sun, Oct 10, 2010 at 8:29 PM, Robert Kluin < > > >> > [email protected] > > >> > > > >wrote: > > > >> > > > > > I think it would be interesting too. Star issue 35. > > ... > > Erfahren Sie mehr » -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
