Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #28 (closed defect: wontfix)

Opened 14 years ago

Last modified 12 years ago

Kid rather slow with lot of markup

Reported by: fneumann Owned by: anonymous
Priority: normal Milestone:
Component: Kid Version: 0.8
Severity: major Keywords:


I noticed my litte app to become slower with each record I added to my (single) db-table.

First I suspected SQLObject. But I found it's query to be quite constant in time.

After some time I came to the conclusion that it must be Kid's markup processing in the py:for-loop that causes the "sluggishness" independent of the actual data.

Here are my testcases, each with the result of a quick apache ab2 benchmark:

<tr py:for="c in components">

ab2 -t 2 http://localhost:8080/
Requests per second:    16.71 [#/sec] (mean)
Time per request:       59.850 [ms] (mean)

Now the same data output with some fancy markup (note: that's a fake example):

<tr py:for="c in components">
		<p>${c.id}<br/><span class="blafoo">${c.info}</span></p>
		<form method="post" action="save">
			<input type="text" name="price" value="${c.price}" />

ab2 -t 2 http://localhost:8080/
Requests per second:    6.30 [#/sec] (mean)
Time per request:       158.609 [ms] (mean)

You see, with only more markup the processing time goes up by factor 3.

In my actual app I have ~30 database records and some more markup in each loop, which let's "Time per request" rise to almost 500ms, which means little more than 2 req/s.

Can we speed this up? If it's the XHTML-validation of Kid may we consider some kind of caching for loops?

Change History

comment:1 Changed 14 years ago by seancazzell@…

  • Summary changed from Kid's py:for-loop rather slow with lot of markup to Kid rather slow with lot of markup

It is not so much the py:for loop construct, but Kid in general that is slow when outputting lots of tags. A py:for loop is just an easy way to end up doing this.

This could get a lot better if Kid is ever able to use cElementTree's native parser. Writing simple HTML and using CSS as much as possible helps too - especially for HTML inside of loops.

comment:2 Changed 13 years ago by bbockelm@…

  • Status changed from new to closed
  • Resolution set to wontfix

I'm not seeing this problem. I've had Kid generate a XML file that is 2.6 MB, consisting of 2950 entries, where each entry has about 15 different tags. It takes about 9 - 10 seconds on my 1.5 Ghz Powerbook.

comment:3 Changed 13 years ago by seancazzell@…

  • Status changed from closed to reopened
  • Resolution wontfix deleted

bbockelm, glad to hear kid is fast enough for your one test case (9-10 seconds still sounds quite slow to me for a 2.6MB file). Don't close tickets that you haven't verified to be a non-issue.

I just re-ran my tests with the latest Kid from svn and am still seeing extremely slow response rate from kid (around 9 pages output per second). Developers should be forewarned that kid is at least an order of magnitude slower than typical template engines.

comment:4 Changed 13 years ago by kristophertate

Has anyone looked into this further? It doesn't seem like there has been much effort put into this. :/

comment:5 Changed 13 years ago by jorge.vargas

  • Severity changed from normal to major

This is the biggest problem of kid.

Kid is slow.

right now we are looking into going away from kid into  http://genshi.edgewall.org/

if you really need a performance boost here for now try chettah

comment:6 Changed 13 years ago by kevin

  • Status changed from reopened to closed
  • Resolution set to wontfix

Genshi improves upon Kid in many ways, including speed. I'm closing this ticket at this point. (Genshi can be used today.)

Note: See TracTickets for help on using tickets.