"Leslie P. Polzer" <[email protected]> writes: > Thanks for sharing your experiences, it's a highly constructive > thing. > > Comments: > >> -- performance sucks and this needs to be worked on (4.5 pages per >> second is nothing to write home about), > > It's surprising to see such bad performance. > > Is this with or without bundling? How many requests does your average > page make?
The number above is from siege -- it's just for the HTML. And it's the right number, because the application sits behind lighttpd which intercepts all static file traffic (this improved things significantly). Bundling is irrelevant, because of a) lighttpd serving static files and b) I'm using CDNs (google and yahoo) for most things. Only weblocks.js, dialog.js and a single CSS file get served from my host. That's why I said bundling doesn't matter to me (and it does break things, I can't follow -dev because of it right now). >> -- common lisp still lives in a pre-unicode world, > > I've hardly had any problems with charsets, and I definitely think > your statement is overly generalizing. > > In my experience SBCL's Unicode support is superior to that of > many other languages and their implementations. Generalizing or not, it is a fact that I have problems related to unicode, on two platforms. Companion work done in Clojure has not had any problems, hence the generalization. >> -- I can't figure out what the performance problems are because the >> SBCL profiler doesn't work for me, > > Have you tried older SBCL versions by now? No, and it is unlikely I will -- things kind of work right now and I just can't dedicate the time for debugging SBCL. >> other limitations: >> >> -- presentations are severely limited because they are not widgets, >> -- views are cool, except when you run into their limitations (see >> above), > > Saikat has made interesting advances here, but I'm not sure > whether he will finish them. I wondered about Saikat's work -- it looked very promising and I was hoping to see it. As it is, I use views mostly in the admin interface, otherwise it's all widgets. [...] >> -- the idea of rendering HTML to a stream isn't necessarily a very good >> one, as you can't render out of order, and juggling string streams >> isn't always what you want to do, > > Got an example, or a more detailed scenario explanation? Sometimes you want to pre-render things like links to images and pass a pre-rendered string to a function that assembles a larger chunk of HTML. As it is now, calling functions that use with-html will render HTML onto the output stream. As a counter-example, I'm writing code in Clojure where every rendering function returns a string and those strings are accumulated into the final output. --J. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
