fruch, please include the rpyc code you used for this test... i can't say without seeing the code. thanks.
besides, as i said before, i don't think speed is the key-point of rpyc -- rpyc does even aim there. of course i'd like it to be fast and efficient, but that's not a design goal. the goals of rpyc are: ease of use, symmetry, and transparency. -tomer An NCO and a Gentleman On Wed, Mar 9, 2011 at 21:26, Fruch <[email protected]> wrote: > I've took pushy for a test drive, > and put it head to head with rpyc, on a use case I've found rpyc a bit slow > > I've did it on two remote modules, one small [39 apis], and one big [237 > apis] > mapping all the api of a remote model to globals() or locals() > (my idea of " from [module] import * ") > > and here are the results: > > *RPyC*: > DEBUG: 11/03/09 21:08:10 | import_to_global took [39] : 3.234000 > DEBUG: 11/03/09 21:08:13 | import_to_local took [39] : 3.250000 > DEBUG: 11/03/09 21:08:37 | import_to_global took [237] : 23.188000 > DEBUG: 11/03/09 21:09:00 | import_to_local took [237] : 23.203000 > ---------------------------------------------------------------------- > Ran 2 tests in 57.109s > > *pushy:* > * > * > DEBUG: 11/03/09 21:11:16 | import_to_global took [39] : 0.312000 > DEBUG: 11/03/09 21:11:16 | import_to_local took [39] : 0.187000 > DEBUG: 11/03/09 21:11:17 | import_to_global took [237] : 1.172000 > DEBUG: 11/03/09 21:11:18 | import_to_local took [237] : 1.094000 > ---------------------------------------------------------------------- > Ran 2 tests in 3.484s > > thats x10 faster for the small module, and x21 faster for the big module. > > and as for simplicity > > *server code:* > > import pushy > pushy.server.run() > > > *client code:* > > import pushy > > c = pushy.client.connect("daemon:localhost") > > print c.modules.platfrom.platfrom > > > > not much PR we can do with that. > > the only thing i've found missing was I'm not sure callback are working > (like filemon demo) > and I haven't found and equivalent of rpyc.async which I think is a neat > idea. > > How about, try to merge those two? (actully porting some of the feature > from rpyc into it ?) > Just a thought... > > >
