On Fri, Nov 24, 2006 at 02:01:55PM +0100, Hrvoje Nikšić wrote:> On Thu, 2006-11-23 at 17:20 +0100, Johan Dahlin wrote:> > You seem to be very worried about performance. > > Only for low-level code, where C would be used for efficiency. Ideally,> calling C methods from C code should be as fast as invoking a function> via a function pointer (possibly achieved by caching the method lookup).> Calling Python from C or C from Python can involve hashtable lookups,> performance is obviously not a priority there.> > > I advise you to try it out and see if it meets your requirements.> > > > If it doesn't, rewrite the whole thing in C.> > Your advice is sound and it works well for most projects. For some> larger projects a bit more planning is needed because by the time the> project reaches a prototype stage, it might be too late to rewrite it in> C. If that is the case then the project manager has no business in softwaredesign and the business deserves a lawsuit by its investors. If it'sonly a prototype, then it is assumed that large portions of the systemmay need to be rearchitected. Anyway, what you are asking for cannot be done with the traditionalhammering out of C and C++ code. C does not provide the introspection features, nor does C++. Getting the static performance with the dynamic features is readily accomplished with a code generator. Have you looked at how pygtk is built. I realize that the system in pygtk is not perfect, but it should give yousome good ideas that in the context of a properly planned large projectshould be easy to pursue. PyGTK basically consists of some s-exprlike definitions that generate many of the wrappers. The problems with the pygtk wrappers (ie those things that requirehand written shit) are mainly due to complexities in certainparts of GTK+ and the want to provide constructs that arevery much comfortable to Python programmers. By lightening up on the last requirment and/or writing objectswith interfaces that are "easy to wrap", you will do away withthese problems. It is also possible to write a code generating system that issmarter than pygtk's, although this will be more complex. The pygtksystem works well considering how simple it is. > The moral of the story is not premature optimization, nor is it my> intention to imply that Python is as slow as Morass (it's in fact> significantly faster, although not by an order of magnitude). The point> is that performance has to be at least considered when choosing the> underlying technology and design, because the underlying technology is>If the project is poorly planned then you are screwed in all cases, nomatter the underlying technology. I think the technology in thiscase is being used as a scapegoat for shitty planning. There have been some amazing large systems done with major components,the keyword being components, in highly dynamic languages. It has beenmy experience that there is almost never a large system where some partof the glue cannot be a "slow" language. It is just the nature of alarge system. -jkl _______________________________________________gtk-list mailing listgtk-list@xxxxxxxxxxxxx://mail.gnome.org/mailman/listinfo/gtk-list
