profiling haml

[dasacc22]

Hey I'm trying to profile haml. I ran the benchmark.rb and looked at
various source files but it was pretty maddening for someone who
doesn't know ruby, and the benchmark was using rails stuff i guess?
Anyway, I wrote a basic haml file and edited my first ruby/haml
benchmark script with some things i learned about haml engine and its
certainly going a lot faster. I would just like to confirm this is
doing what I actually think its doing

---
require 'rubygems'
require 'haml'

f = File.open('test.haml')
engine = Haml::Engine.new(f.read)

times = []
for i in (1..2000)
beginning = Time.now
engine.render
times << Time.now-beginning
end

puts "#{times.min}"
---

I am getting a fast response time with my test template. Now when i
instantiate engine, this is precompiling the template, correct? so
when i call render, this is evaluating the template, correct? And if
so, is this the normal use case? I read on nex3's blog that the
caching(compilation?) isn't normally made use of in most
circumstances.

And if anyone has a hint(cant make it too easy on me) on where exactly
I'm suppose to enable :ugly without getting some kind of constant
error, please let me know.

--
You received this message because you are subscribed to the Google Groups "Haml Dev" group.
To post to this group, send email to haml...@googlegroups.com.
To unsubscribe from this group, send email to haml-dev+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/haml-dev?hl=en.

[Nathan Weizenbaum]

Benchmarking Haml across implementations is kind of a tricky game. The Ruby implementation, at least, is optimized for the most common use-case of processing dynamic Ruby code once per request. This means that the vast majority of the optimization goes into speeding up the code-generation, while the parsing is left to be as slow as it ends up being.

The upshot of this is that Haml precompiles almost everything it can to a string, which gets concatted with dynamic code. This means that if you use the cached mode that I normally recommend for benchmarks, it'll be basically instantaneous, but if you include the parse time it may well be dog-slow.

I'm not sure what the best way out of this is. To what purpose were you planning to put these benchmarks.

[dasacc22]

My only real purpose is to set myself straight on how exactly HAML
works so I dont inadvertantly say things that aren't true. And to get
concrete numbers for how this relates to the python crowd.

My initial tests with haml *were* dog slow b/c I accounted for the
initial parse time. But in the same breath I didn't think much of it
b/c it faired only slightly worse then django templates (with the
templates pre-compiled sadly in retrospect).

Benchmarking haml with the templates precompiled and simply waiting on
the context was beyond my scope of knowledge when i initially tested
it. Currently with a test template taken from the website, on my
laptop, haml handles the render at about .000109 ms which I guess
would be the near instantaneousness you speak of.

Currently the same template processed by DAML on the fly with no
precompilation of any sort takes aproximately .000201 ms, and I still
have a lot I want to do for speed and features so I imagine once I am
done itll probably fall right back to that point for a while

Again its a bit of a tricky matter as I guess the only thing the
django crowd can do is inline django templates with basic haml. And if
a django user was interested in overall speed, and did not want to
give up the use of django templates, I'd want to be able to say either
or. "well a django/haml combo will probably win by roughly a [%]
margin right now over mixing django/daml until some more development
goes into daml" or "if your looking to replace django templates
completely with a single solution, daml can fit your needs" or w/e the
case exactly.

This kind of talk is probably far off. I have seen some interest in
different areas for daml, but theres still a lot I want to implement,
and along the way I'm doing testing like this (and asking questions
like this) to increase my knowledge of ruby/haml in general just to be
able to make general advisements.

Cause theres nothin like misinformation

> > haml-dev+u...@googlegroups.com<haml-dev%2Bunsubscribe@googlegroups.c om>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/haml-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "Haml Dev" group.
> To post to this group, send email to haml...@googlegroups.com.
> To unsubscribe from this group, send email to haml-dev+u...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/haml-dev?hl=en.

[dasacc22]

also I was wondering if haml supports precompiling a template to a .rb
file. I was digging through documentation but couldn't find anything
related. I know something like this, to take advantage haml's caching,
would make it much more attractive for integration into other-
language's template solutions speed-wise. I know for example, cheetah
templates for python enables compilation of templates into py files
(or even pyc or pyo from there) for faster renders.

Although i've seen a comment or two about using haml with django, I'm
just not finding any information on it. And I'd love to get a working
example of haml integrated with [xyz] templates.

> > > haml-dev+u...@googlegroups.com<haml-dev%2Bunsubscr...@googlegroups.c om>

[dasacc22]

actually thinking about it, i guess this isn't even the way to roll
since one cant take advantage of various aspects available with haml.
Trying to figure out limitations for such. like

:markdown
{{some_django_md_content}}

I guess maybe there's a line you can choose to cross or not cross when
mixing solutions making certain features of haml unavailable based on
precedence of dynamic content