@domikon,

> 
> Hey, I'm not too sure that 2 full time Google engineers working on this can 
> be labeled as "artisanal engineering" Smile). 
> 


Compared to the dozens of top engineering years that have been invested and are 
still kept invested in the Java Virtual Machine, it can be seen as "artisanal 
engineering" I think. It remembers me other guys attempting to re-code a full 
blown JIT engine fore other non trivial languages: remember Parrot, Rubinius, 
Yarv... Nothing approaching a good JVM. I think you have no idea what the JVM 
is doing to optimize code execution. TraceMonkey and V8 JIT are joke compared 
to the JVM and Javascript is a simpler language than Python...




> So when somebody is willing to fix those issues and that somebody's name is 
> google

Unfortunately, Unladen won't fix the GIL. They said they will stick to the 
CPython behavior and Von Rossum said they won't remove the GIL, indeed they 
were unable to remove it without running notoriously slower and they don't 
won't to pay that cost in general.
Even when you will have removed the GIL, lot's of library won't behave well in 
a multithreaded environment.
Now if you want to remove the GIL, go Jython, it inherit the exceptional JVM 
multi-threading abilities, even Von Rossum recommend that. Watch the Pycon 
interview, Unladen is mainly about adding trivial JIT to the CPython bytcecode 
interpreter hoping it will run significantly faster  already.


> BTW, how is OpenERP-on-Jython-Round-2 doing? 

Well I did my part. Sun contacted Tiny SPRL, may be they are interrested, now 
they should know it's doable for a reasonable effort. Tiny said they will 
remove mx.Datetime from the server which is half of the compatibility 
bottleneck. Next I think I'll prove you can put openerp-server behind a 
standard J2EE server like Tomcat or Glassfish by making it WSGI compliant (smal 
XMLRPCServer hack) and putting it behind Modjy which is now part of the regular 
Jython 2.5 distro. But as I said, I'm doing that on my little spare time so 
far, so the effort has to be carried buy larger actors.



> You are thus confirming that an OpenERP server can accept only 1 
> '''concurrent''' user at a time. Can you elaborate further on that particular 
> point?
> Raphaël, does this also happen with Jython? 


I think you should fire multiple servers (e.g. process), just like the 
web-client fires at least 2 process by default.

On Jython I think multi-threading will be native once you put OpenERP
behind a standard JEE+Modjy server (natively multithreaded; see Django+Modjy). 
Still I'm not to sure it will work properly as the OpenERP ORM isn't probably 
writtent to handle concurrency correctly (some ORM like Hibernate are, most of 
other aren't, Rails ActiveRecord took a time to become threadsafe recently). 
Anyway J2EE servers allow to forbid concurrent requests.

Anyway, it doesn't matter generally speaking. People are using PHP and PHP is 
even worst regarding to those points (much slower than Python and not 
multi-threaded either), so yeah Python is not Java but usually what matters for 
an ERP are the features and the TCO, not the brute force perf. And thanks to 
it's code productivity, OpenERP got an ORM+architecture that is not too bad. 
Take Compiere or Openbravo they claim they are Java based (they are more pl/SQL 
rooted actually) and I'm quite sure they eat a lot more resources because they 
constantly send and re-send the same stupide SQL queries to the poor database 
because they don't use a smart ORM cache 90% of the time (and given we are 
speaking about millions of SQL lines, it won't change any time soon). and I'm 
not even speaking here about their poor features set.


@sraps,

Luckily there were tons of improvements in OpenERP 5 vs 4.2 so even if 
concurrency is not yet possible without starting several instances, server 
requests are often faster so you don't feel latency to often. Improvements were:
- faster reports
- MPTT SQL model for hierachical data like accounting and stock
- better ORM cache
- fields related
- SQL "transactional cache" using store=True or invalidation trigger methods 
hash
- tons of web-client improvements


Raphaël Valyi

------------------------
http://www.smile.fr




-------------------- m2f --------------------

--
http://www.openobject.com/forum/viewtopic.php?p=34365#34365

-------------------- m2f --------------------


_______________________________________________
Tinyerp-users mailing list
http://tiny.be/mailman/listinfo/tinyerp-users

Reply via email to