Mako vs Genshi?
Mark Ramm
with tg1.x. So, we definitely need to support it. But genshi will
always be slower than Mako. And mako has lots of page fragment
caching features which are very nice for high traffic sites.
People who have lots of traffic, or want the lowest possible latency,
will probably always benefit from using mako, and if we start building
reusable turbogears components, it would make sense to use mako since
that would make them re-usable for the widest variety of people.
As I see it we have a few options:
1) Make Gehsh the default, use Genshi in components, and leave the
speed daemons to do stuff on their own.
2) make mako the default, use mako to build components, and break
backwards compatibility
3) try to get component developers to provide both Genshi and Mako
versions (ToscaWidgets does this to some extent IIRC).
I'm concerned that option 1 limits the performace/scalability of tg2,
and option 2 is too big of a change from tg1. And I'm not sure how
much work 3 is, but I'm guessing that it's not insignificant, so it
will limit the number of components that get developed.
What do you all think?
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Ian Bicking
> So, I like Genshi, and it's definitely more "backwards compatable"
> with tg1.x. So, we definitely need to support it. But genshi will
> always be slower than Mako.
Genshi may be, but I don't think a tag-based template *has* to be
slower. Alex Limi (Plone guy) and... some people at Google, I forget
who, have been playing around with a replacement for ZPT that is
supposed to be quite fast, and in the same range as Mako. Blast if I
know the name of it. And it's not exactly public. But anyway, Genshi
isn't slow because that style of template language has to be slow.
--
Ian Bicking : ia...@colorstudy.com : http://blog.ianbicking.org
Mark Ramm
> isn't slow because that style of template language has to be slow.
And Genshi is way faster than Kid, so TG2 will be faster than TG1,
it's just not as fast as Mako.
I probably should have linked here off the bat, as they have actual numbers:
Jorge Godoy
>
> As I see it we have a few options:
>
> 1) Make Gehsh the default, use Genshi in components, and leave the
> speed daemons to do stuff on their own.
> 2) make mako the default, use mako to build components, and break
> backwards compatibility
> 3) try to get component developers to provide both Genshi and Mako
> versions (ToscaWidgets does this to some extent IIRC).
I believe that whoever needs such performance will be "fluent" in Mako and
will be able to translate widgets templates from Genshi to Mako. With this
simple template change they will hava Mako everywhere and that's it: fast
site.
I prefer having 1) because it makes it easier for people that are familiar
with HTML, XML and also makes it easier for us to guarantee the well
formedness of generated code, not to mention that it makes it easier to
migrate from TG1 to TG2 (otherwise we'd really see a fork of the project...)
and having just Genshi to learn to deal with template code for controllers
and for widgets is better than having to learn Genshi and a bit of Mako to
understand / change widgets.
Who needs speed is not a newbie and is able to dig a bit further to squeeze
all what he / she can.
--
Jorge Godoy <jgo...@gmail.com>
Diez B. Roggisch
IMHO what TG needs is features. People on the ML often refuse to dive into
intricacies of e.g. AJAX, remote forms and the like - they want solutions to
their problems.
So I think we should use what helps us to whip out components and features as
fast and completetely as possible. Which IMHO is genshi. Developer time is
more precious than CPU-cycles.
Just the other day I read about youtube and their strategy to enable high
perfomance, while using python. And I think that points into the same
direction: raw processing speed never wins by itself - you need to carefully
tune you application, sure. But competition in the market is about features -
you can have the fastest C-backend to server videos - if it sucks
featurewise, nobody will use it.
Diez
percious
goodbye. I am basing my project on Genshi because that is what
twAjaxTools is using right now and I think the performance cost is
worth it. Whenever toscawidgets converts over to Mako I will too. I
will add a ticket to my project to chage over to Mako, but it is going
in the v0.4+ folder. Toscawidgets is "sort of" supporting mako, but
the conversion seems to be going slowly and I want to move fast on
dbsprockets. Maybe Alberto and Claudio will comment on Mako?
-chris
Kevin Horn
a) Please for the love of all that is holy, let's not change the plan AGAIN! It has been said and resaid on this ML that "Genshi will be the default in TG2". Even as similar as Genshi is to Kid, it caused a pretty big uproar. The speed argument did not convince people then. The big advantage to Genshi that actually convinced people (IMO) was the improved error reporting, and the fact that Kid was only semi-maintained. Switching to Mako as default I think will tick off a fair amount of people.
b) As Diez said, "Developer time is more precious than CPU-cycles." I find xml-based templating drastically cuts down on time of development, and makes it easier to coordinate with a separate developer. The developer time we save by not changing over can be used to work on features that were very exciting and attractive to the user community when TG 0.8 was launched, and have been largely unmaintained since. (Catwalk, Model Designer, etc.)
c) If I were to use something besides Genshi/Kid, I would spend way more time validating pages, etc. Ick. :)
I don't think TG was envisioned as the "Framework for making fast apps". IMO it was designed to reduce grunt-work and repetitiveness for the developer. Let's stick to that philosophy.
Kevin Horn
Jonathan LaCour
> I don't think TG was envisioned as the "Framework for making fast
> apps". IMO it was designed to reduce grunt-work and repetitiveness
> for the developer. Let's stick to that philosophy.
This 100% summarizes my opinion. Lets stick with the plan thats been
in place for some time now, and focus on developer productivity, not
shaving a few milliseconds off rendering our templates.
--
Jonathan LaCour
http://cleverdevil.org
Christoph Zwerschke
> This 100% summarizes my opinion. Lets stick with the plan thats been
> in place for some time now, and focus on developer productivity, not
> shaving a few milliseconds off rendering our templates.
That's my opinion, too. I originally chose TurboGears over Django
because of the Kid templates (and I consider Genshi as Kid 2.0). The
concept behind Kid is really something special and one of the core
distinguishing features of TG.
In the past it clearly turned out that one of the main problems of TG
were the too many "default" options and ramifications. While this may
not be a problem or even desirable from a technical point of view, it is
in fact a big problem from a psychological viewpoint. New users are
often overwhelmed by the many decisions they have to make when choosing
between SA and SO, Kid, Genshi, Mako or Cheetah, mochikit or dojo etc.
We more experienced users tend to think people should be happy about so
many options, but in reality it frightens people away.
That is similar to a well-known phenomenon in consumerism:
http://www.apa.org/monitor/jun04/toomany.html
TG must come back to the point where it offers *one* recommended and
well-supported stack of components. Experts can then replace or
supplement these components with other components, and there should be
recipes for doing so, but these alternatives should not be offered as
part of the "standard" or as equivalent alternatives that users have to
pick from before starting.
One of the values of a framework like TG is that others have already
made (good) decisions for you. This makes life easy and developing
enjoyable, as long as it is possible to override these decisions and
choosing something else when your situation really requires this.
This is nothing more than the old TG slogan "Keep simple things simple
and make complex things possible". If you have too many decisions to
make, then simple things start to become complex.
-- Chris
Alberto Valverde
> Without support for Genshi you can pretty much kiss dbsprockets
> goodbye. I am basing my project on Genshi because that is what
> twAjaxTools is using right now and I think the performance cost is
> worth it. Whenever toscawidgets converts over to Mako I will too. I
> will add a ticket to my project to chage over to Mako, but it is going
> in the v0.4+ folder. Toscawidgets is "sort of" supporting mako, but
> the conversion seems to be going slowly and I want to move fast on
> dbsprockets. Maybe Alberto and Claudio will comment on Mako?
twForms has all its templates available in Mako flavour thanks to Roger
who ported them this summer. I've been using twForms and Mako in a project
recently and the combination worked pretty well so I'd say ToscaWidgets
"fully supports" Mako :)
twAjaxTools is another story... I don't think it uses Mako for templates
but porting a template to Mako is pretty easy (take a look at twForms').
Regardless of templates being ported or not, mixing templates in different
languages *is* supported (with plenty of unittests and real-world
experience proving it)
Regarding the topic of this thread: I'm +1 on sticking with Genshi as the
default.
Alberto
Alberto Valverde
> Without support for Genshi you can pretty much kiss dbsprockets
> goodbye. I am basing my project on Genshi because that is what
> twAjaxTools is using right now and I think the performance cost is
> worth it. Whenever toscawidgets converts over to Mako I will too. I
> will add a ticket to my project to chage over to Mako, but it is going
> in the v0.4+ folder. Toscawidgets is "sort of" supporting mako, but
> the conversion seems to be going slowly and I want to move fast on
> dbsprockets. Maybe Alberto and Claudio will comment on Mako?
twForms has all its templates available in Mako flavour thanks to Roger
Kevin Horn
TG must come back to the point where it offers *one* recommended and
well-supported stack of components. Experts can then replace or
supplement these components with other components, and there should be
recipes for doing so, but these alternatives should not be offered as
part of the "standard" or as equivalent alternatives that users have to
pick from before starting.
One of the values of a framework like TG is that others have already
made (good) decisions for you. This makes life easy and developing
enjoyable, as long as it is possible to override these decisions and
choosing something else when your situation really requires this.
This is nothing more than the old TG slogan "Keep simple things simple
and make complex things possible". If you have too many decisions to
make, then simple things start to become complex.
-- Chris
Kevin Horn
Lukasz Szybalski
Is there a reason why cheetah is not on the link you mentioned?
Mark Ramm
Only because they didn't test it. But if you're really interested I
belive the Mako docs have an older comparison using a similar test set
(which isn't up to date on the latest Genshi performance
enhancements), and they include Cheetah as a reference.
Mark Ramm
I never really thought that option 2 was viable, so in my mind we were
really going between 1 and 3, and I think that the right answer is to
do 1 for now, and let people who have crazy performance optimization
needs help us out by adding Mako templates to components as the need
arises.
So, where it's reasonably easy, we should make it possible to have
both Genshi and Mako templates in various components, but for most
things we can safely assume Genshi, and deal with the mako/performance
issues as they come up.
--Mark Ramm
Lukasz Szybalski
from maco website:
Mako: 1.10 ms Myghty: 4.52 ms
Cheetah:1.10 ms Genshi: 11.46 ms
Django: 2.74 ms Kid: 14.54 ms
That was the only reference I found. So if mako and cheetah are at the
same speed and we support cheetah then cheetah would be my first
choice if I wanted speed I think. Unless there are other reasons. I
couldn't find any other compressions of the two do.
Mark Ramm
> Mako: 1.10 ms Myghty: 4.52 ms
> Cheetah:1.10 ms Genshi: 11.46 ms
> Django: 2.74 ms Kid: 14.54 ms
>
> That was the only reference I found. So if mako and cheetah are at the
> same speed and we support cheetah then cheetah would be my first
> choice if I wanted speed I think. Unless there are other reasons. I
> couldn't find any other compressions of the two do.
Well, Mako is pure python, and that cheetah score is with C speedups.
And Mako provides template composition, caching, and other tools that
Cheetah does not. No matter what we do, we won't drop cheetah
support, but I have not had the same number of people pushing me to
use Cheetah in TG2 as I have Mako. And Pylons defaults to Mako, not
cheetah, so if we are going to be different I want it to be for good
reasons, and I just don't think Cheetah has enough advantages over
Mako to be worth that.
zunzun
>
> ...let people who have crazy performance optimization
> arises.
but your business customers will surely understand the slow web site
and be sympathetic to you once they know it's Turbo Gears!"
James
percious
It comes down to
a matter of cost. If it is easier for a developer to use Genshi, and
then you have to buy
a few more servers to get the performance you need, you will probably
still come out
ahead in the long run.
I think Mark is spot on, Genshi, with support for Mako sounds like a
mating of both
worlds, just like TG has always been, willing to play with many
different package.
-chris
Mark Ramm
> but your business customers will surely understand the slow web site
> and be sympathetic to you once they know it's Turbo Gears!"
If your whole page creation time is spent in template rendering, you
have an amazingly fast network connection, web server, database layer,
etc. Sure, template rendering may be slower, but overall you may
find that TG2 is fast enough, and more scalable than many of the
competitor frameworks, even with Genshi. And the fact that SQLAlchemy
provides methods for data partitioning (sharding) and many more
single-query database operations than the competitors is likely to
make more difference than template performance.
And, of course you will be able to use Mako for projects that need it.
zunzun
>
> And, of course you will be able to use Mako for projects that need it.
strong performance arguments against using TG. Still some
performance arguments, just no strong ones:
"I heard it renders slowly."
"Ah, but we *can* use Mako where we need to."
"Oh. Uhhh, ahhhh, hmmm, well..."
James
Jorge Godoy
And I imagine: "Sure boss! I will just swap the default for this other
specialist option (see how the raise you gave me paid itself?) to get 10x
more performance!".
--
Jorge Godoy <jgo...@gmail.com>
zunzun
On Dec 15, 7:07 am, Jorge Godoy <jgo...@gmail.com> wrote:
>
> And I imagine: "Sure boss! I will just swap the default for this other
> specialist option (see how the raise you gave me paid itself?) to get 10x
> more performance!".
at all,
now that is really cool and helpful. Thanks, Jorge! I'm really
looking forward
to trying TG2 since this will be so simple to do.
James