I haven't used the AWS centos setup, so was delaying to see if anyone had. A few general comments ...
With robot framework, the performance limits we have found are usually memory intensiveness causing gc. Our setup is quite hungry for PermGen before 1.8 (we recently upgraded). There's quite a few temporary objects created as well. Given we are talking about multiple layers of interpreted languages I don't think that's unreasonable from a design perspective but it is worth being aware of. We also have internal data structures like message queues created for each test case for our own reasons (we have a message driven app). This exacerbates it.
We have found that if multiple layers of BDD functions are used (keywords or directives in robot-lingo), this is again more intense. Refactoring the inner functions into Python or Java shows improvements pretty quickly. Not that surprising perhaps but just a data point for others in this setup.
On a tangent, Michael Feathers had an interesting post about "starting dynamic and ending statically" recently that is very similar to this refactoring / optimization.
I think he is actually suggesting future language / tooling design could support this sort of workflow to be a routine daily thing instead of a refactoring done over weeks or months. Would be curious if anyone in this crowd has thought about that too.
I also implemented this stack for my work's automated test runs, but with python robot. I have noticed though the robot python packages running exceptionally slow on (aws) centos. I wanted to know if others ever encountered such an issue?
I love jython and use it frequently, and have over 3 decades of programming experience----so not quite a newbie.
Jython works like magic for the most part but the integration is so slick sometimes I forget which platform I'm on. The Java objects start looking like python objects and vice versa (which is the whole point, after all), but it can be a bit confusing---even though it all just works.
So...I'm willing to cut the newbies some slack on their confusion here.
It doesn't, of course - it looks like a reaction from a beginner who hasn't learnt to contextually separate a language from the platform surrounding it.
It might speak to the need for clearer doco entry points, though. The dominance (and usefulness) of stackoverflow for new programmers is also interesting. Because the foundation of jython predates it, there's not as much of a community around Jython there, that I've seen.
We made the wiki closed to anon edits because of nasty spam problems, but contributors are very welcome - just ask on this mailing list.
> 在 17 Sep 2016，8:32 AM，Michael Chisholm <[hidden email]> 写道：
> On 9/16/2016 1:13 PM, Guzdial, Mark wrote:
>>> Apparently a lot of new programmers are being introduced to programming through CPython ... shouldn't the poor kids be learning Jython instead?
>> Actually, many of the students at University who are learning Python are actually learning Jython. The textbook that Barbara Ericson and I wrote uses Jython: https://www.amazon.com/Introduction-Computing-Programming-Python-4th/dp/0134025547. Last I saw market analysis, it's the third most popular Python University textbook, at least in the US. If you read the reviews for the book, you'll see that lots of people are confused about Jython vs. Python. Quoting one:
>> This book is a prescribed text for a course: that's the only reason to buy it. Its biggest problem: false advertising. This is NOT a book on Python, it's about JYTHON - A Java based imitation of Python.
>> Why? Well, there's some pretty software, available to download, which uses the the JRE. The author chose to stick with this "easy learning environment" and basically cripple anyone wanting to write Python code for Blender, Maya, Android etc.
>> You may learn to program from this text, but don't expect a trouble-free life when you get exposed to the real language.
>> The IDE that we wrote for the book, JES, is all Jython, and has been used by thousands of students for over a decade now: See http://cacm.acm.org/blogs/blog-cacm/205801-14-years-of-a-learner-centered-python-ide/fulltext
> So I'll just ask the obvious: CPython and Jython are supposed to be
> alternative implementations of the same language, Python. IronPython is
> another. How does a different implementation imply a different language?
> Jython-users mailing list
> [hidden email]