Logicus has asked for the wisdom of the Perl Monks concerning the following question:

Just found this : Eval::Compile

I was thinking this might solve the performance issue in my system of evalling the plugin strings, but it says it is not ready and is not thread safe... so my question is, what problems might arise from it being non thread safe?

On a side note...

I really don't want to make the plugin code more complex, just for the sake of saving a few clock ticks. Right now the plugins are very simple to write, and various suggestions that have been made by folks like corion, required that I change the way the plugins work.

For instance under corions way of doing it, the plugin should create perl which does a given task, rather than simply being the perl which does the task, so that the parser creates a perl program from the aXML document once and that program gets stored. That's very nice, and would be very fast, but it means the plugins would be a lot harder to code and one of the aims of the system in the first place was to make things easy!

Keep it simple...

Replies are listed 'Best First'.
Re: hrm, Eval::Compile
by MidLifeXis (Monsignor) on Jul 20, 2011 at 09:28 UTC

    There are two sections to your post: theory, and practice. When asking about something in practice, it would be helpful to provide some context -- even just a link to previous discussions.

    One way to think about it to ask yourself if this post makes sense by itself. If there are other references needed to make sense of your question, or if there are bits of information and knowledge needed (beyond some assumed baseline) that relate to the question, it would be good to provide a link to them.

    --MidLifeXis

[reply]
Re: hrm, Eval::Compile
by Anonymous Monk on Jul 20, 2011 at 05:13 UTC

    but it means the plugins would be a lot harder to code

    No it doesn't -- the way you code plugins wouldn't change one bit

[reply]

      Ok, so I've gone away and had a think about that and I think I can see a way of organising it so that the plugins can remain the same, however there is still another problem.

      lets say you have a situation like this:

      
  (foo)
    <bar><x/></bar>
  (/foo)

      [download]

      Where for instance foo does a database lookup and for each row of the database returns <bar> with the x value filled in. Now we have a certain number of <bar> directives to compute, the number of which is unknown until foo has been computed.

      Each time the program runs there could be a different number of rows retrieved from the database, so unless we compile each time, negating the point of the excercise, there is no way to know how many instances of the compiled <bar> directive to include in the precompiled file.

[reply]
[d/l]

        Each time the program runs there could be a different number of rows retrieved from the database, so unless we compile each time, negating the point of the excercise, there is no way to know how many instances of the compiled <bar> directive to include in the precompiled file.

        What? That is a simple foreach loop, as already demonstrated in Re: H.O.P && aXML, Re^4: RFC : Abstraction Markup, Re^7: H.O.P && aXML, Re^7: H.O.P && aXML

[reply]

Back to Seekers of Perl Wisdom