puzzler a écrit :
> > I don't know much about your background so please forgive me if I give
> > you obvious advises, but perhaps you'd be better *first* coding the
> > solution to your problem - eventually looking for help on
> > comp.lang.python. Then you'll have real facts, not estimations.
> > Specially if yourcomputationhappens to be memory-hungry, since the
> > best way to put a server on it's knees is to make it go swapping. So
> > in your case, you may want to look for space optimisation instead of
> > time optimisation.
>
> Well, yes, but I'm trying to decide what language to use to program
> this computation. Since my web framework is written entirely in
> Django, there's a bit of an advantage to using Python, just in terms
> of seamlessly calling the function from Django (but do I use separate
> threads, separate process, or do I not even need to worry about
> that?). But I can probably get a hundred-fold speedup by using a
> statically-typed, compiled language. But then I am forced to use a
> separate os process to call the program (more heavyweight than
> threads?), and need to find a language with an API to manipulate the
> database, worry about privileges, etc.
First point : if your computation happens to be that "intensive", you
don't want to call it 'in process'. It just won't scale. So you do
have to use separate processes - possibly on different machines.
Second point : if you computation only depends on it's inputs (which
you said was the case), then you just don't have to worry about
database access - this will still be handled by your Django app. All
you need is a way to invoke the computation process with appropriate
params, and a way to know when it's done and get the result back. All
this - inter process communication - is far from rocket science, and
has long been solved in quite a lot of ways.
Third point : all this is based on "wet finger" estimate. So it's just
worth nothing. Experience proved that we developpers can be very bad
at this kind of guessing games. IOW, until you have facts, you just
don't know.
So, to make a long story short, don't bother about this for now, and
start writing code. Start in Python, benchmark, profile, and then
you'll at least have a clue as what the real constraints are and what
the appropriate strategy might be.
> That's why I'm asking now, ahead of programming, for more info about
> how hard it is to incorporate an intensive computation into the Django
> framework.
Stop worrying about django, it's has nothing to do with it. And don't
worry about how Python can communicate with either another process
(whatever langage has been used to implement the program) or a C-coded
library or whatever.
> It could very well affect my choice of language.
Python is good for prototyping, and it's the main language used in
your app. So start with Python. Once you'll have something up and
running, you'll have hard facts wrt/ time-space problem, and it will
*then* be time considering alternate solutions. IOW : don't worry
about Django, don't worry about how Django, don't worrry about Python,
and *write this damn code*. I repeat : until you do have working code,
everrything else is just blah blah, waste of time and premature
optimization.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
