Re: rough start of an axml compiler

The only comment I might make is that anytime you have a function you're passing craploads of parameters to, that you may be in a position where you'd be better served by using an object to manage the storage. Internally (in methods inside the class), you can go ahead and keep referencing things directly for speed.

If I understand your architecture properly, you have several invariants that are getting set up in sortofcompileit on every call; if you pulled those out into package variables and set them up once (with an init method/sub), you'd save time on every subsequent call.

And this it totally headed in a good direction - real "compilation" of the aXML code! If you memoized (cf. Memoize) the calls to sortofcompile, you might be able to get another free speedup from Memoize's caching. As long as a given parameter set always results in the same output, Memoize will help. If there are side effects that might change the result, then it won't help (e.g., memoizing a random number generator would make it seriously unusable, if very fast!).

Comment on Re: rough start of an axml compiler

Replies are listed 'Best First'.
Re^2: rough start of an axml compiler by Logicus (Initiate) on Jul 21, 2011 at 19:53 UTC
The idea was to run `sortofcompileit` only once per page, the first time it is accessed and to save it's output so that henceforth you can skip that step unless the source-code has been updated. All it does is reorganise the raw aXML code into a more efficient layout which can be processed a lot faster for individual page hits. I don't like it because that method, no matter how cleverly implemented breaks certain plugins which are designed to exploit the runtime parsing setup. If you wanted to use aXML for a large scale site and server overhead was a real budgeting concern then it would be neccesary to sacrifice said plugins (and the groovy effects they achieve), in order to run a compilation/optimisation schema like what the above code is starting to do. TIMTOWTDI even with aXML/Perl	[reply] [d/l]
Re^3: rough start of an axml compiler by pemungkah (Priest) on Jul 22, 2011 at 06:35 UTC
Just as a throw-it-out-there, how about adding markup (or detecting, depending on how sophisticated you want to be) that delineates the "definitely dynamic" and "for-sure static" portions of a page? You could pre-build whatever was invariant (I seem to be using that word a lot lately...) and reserve the slower dynamic stuff for just the part(s) that needed it.	[reply]
Re^4: rough start of an axml compiler by Logicus (Initiate) on Jul 22, 2011 at 06:42 UTC
That's exactly what the `sortofcompileit` function does! if you run that code, you will find it spits out a bunch of print statements interspersed with print axml statements, which would call a subroutine called axml to compute the dynamic aXML bits. The approach would work, and it would save server time, but I just feel that given how fast servers are these days I'd rather keep my own version completely dynamic, and retain the more funky plugins which exploit the way the existing parser works rather than accept limitations on it and how it works and by setting syntax in stone for the benefit of the compiler stage. (which debates in CB seem to have concluded to be required) That is not to say that anyone who wants to isn't free to do exactly whatever they please with aXML, be that file it in the rubbish bin, or write their own faster/better/more efficient version or whatever, it doesn't matter to me, I let go of controlling where aXML goes the moment I decided to opensource the code and concept to the world.	[reply] [d/l]