> I took a look and traced the bottleneck to lines 125 and 127 in
> viewPlan.html. The problem was as Malcolm hinted -- you're
> doing a foreign key lookup ({{ workout.workoutType.name }})
> for each iteration of the for loop.
>
> I changed line 55 of views.py to use select_related() instead
> of
Derek Lee-Wo wrote:
> The app I have is pretty simply as I'm just beginning so I didn't
> bother to try and make it any smaller. I've ZIPped the entire
> project directory and it can be downloaded here:
>
> http://www.roadtoboston.com/media/RoadToBoston.zip
>
>
I took a look and traced the b
The app I have is pretty simply as I'm just beginning so I didn't
bother to try and make it any smaller. I've ZIPped the entire project
directory and it can be downloaded here:
http://www.roadtoboston.com/media/RoadToBoston.zip
I have a batch file called runserver.cmd that would run the local t
On Fri, 2007-02-09 at 16:06 -0600, Derek Lee-Wo wrote:
> > It may take a couple more days to work this out. It's only been 48 hours
> > since you posted the original problem and less than 24 hours since you
> > posted a portion of your code that causes the problem. It is very
> > unusual behaviour
On 2/9/07, Derek Lee-Wo <[EMAIL PROTECTED]> wrote:
...
> My original post was to really geared to finding any resources that
> might give some best-practice guidelines Barring that, I was really
> only hoping for any quick or easy suggestions others may have.
In general, Django templating is ver
> It may take a couple more days to work this out. It's only been 48 hours
> since you posted the original problem and less than 24 hours since you
> posted a portion of your code that causes the problem. It is very
> unusual behaviour for Django; the templating code is normally very fast,
> but t
I'll put together a zip file of my entire project directory along with
a MySQL dump of the test data I have. That way, it should be easy for
anyone to play around with it. I'll try do that later this evening
On 2/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-02-08 at 20:
On Thu, 2007-02-08 at 20:21 -0600, Derek Lee-Wo wrote:
> > One more idea: It looks like you're doing foreign-key lookups in the
> > rendering.
> >
> > {% for workoutWeek in workoutWeeks %}
> > ...
> > {% for workoutDay in workoutWeek.workouts %}
>
> workoutWeek isn't a table, but I'm pretty sure
On Fri, 2007-02-09 at 13:41 -0600, Derek Lee-Wo wrote:
> I incorporated ReportLib to generate a PDF of the same data that I'm
> trying to display on the web and the PDF gets created in about 2
> seconds as compared to the template via Django which is taking 16-18
> seconds.
>
> Both routines shar
At 02:41 PM 2/9/2007, you wrote:
>This is turning out to be very distressing. I'm starting to look at
>other template options. I may give Cheetah a try this weekend.
I'm not surprised you are considering alternatives, 16-18 seconds is
an unacceptable amount of time for template rendering. Did
I incorporated ReportLib to generate a PDF of the same data that I'm
trying to display on the web and the PDF gets created in about 2
seconds as compared to the template via Django which is taking 16-18
seconds.
Both routines share a common method that does all the data retrieval
and manipulation
This is a total shot in the dark but are you running with the fix for ticket
#3441? If your template does anything to cause VariableDoesNotExist to be
raised during rendering, #3441 might apply. Without the fix the entire
contents of your context is repr'd to build the exception message that is
t
On 2/8/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
...
> If not, just how many rows are we talking? How big is the final,
> rendered template?
One more idea: It looks like you're doing foreign-key lookups in the rendering.
{% for workoutWeek in workoutWeeks %}
...
{% for workoutDay in workoutWe
On 2/8/07, Derek Lee-Wo <[EMAIL PROTECTED]> wrote:
...
> I added a timing statement at the entrance and exit of render() and
> just inside the foreach loop. I got over 3,000 lines output!!
That depends largely on how many rows you have in the forloop, I imagine.
Anyway, none of them stood out a
> I did as you suggested and the call template.render() is where the
> 16-18 seconds are being spent. My next step is to add some timings to
> django.template.NodeList.render as you suggested.
I added a timing statement at the entrance and exit of render() and
just inside the foreach loop. I go
> You'll want to do something like this, timing each line:
>
> from django.template import loader
>
> source, origin = find_template_source('your_template_name')
> template = get_template_from_string(source, origin, 'your_template_name')
> template.render(your_context)
>
> --
>
> It ma
On 2/8/07, Derek Lee-Wo <[EMAIL PROTECTED]> wrote:
> I wasn't aware of that, but in my case, I am processing the data
> before I render the template. I actually loop though all the records
> and do some processing so I know the SQL queries are occurring within
> the 0.5 seconds I mentioned above.
> > My app does a bunch of database queries and processing and when I
> > timed that part, it all completes within 0.5 seconds, but the call to
> > render_to_response() takes 18 seconds. Needless to say, the end-user
> > experience isn't acceptable.
>
> I don't know if you are aware about the fac
On Feb 7, 10:58 pm, "Derek Lee-Wo" <[EMAIL PROTECTED]> wrote:
> My app does a bunch of database queries and processing and when I
> timed that part, it all completes within 0.5 seconds, but the call to
> render_to_response() takes 18 seconds. Needless to say, the end-user
> experience isn't ac
19 matches
Mail list logo
