--- On Wed, 12/31/08, David E Jones <[email protected]> wrote:
> > --- On Tue, 12/30/08, David E Jones
> <[email protected]> wrote:
> >> If you're really worried about it you could do
> >> something to load all existing simple-method,
> screen, etc
> >> files and see what the actual size of the cache
> is. This is
> >> really easy to do since if you run the Artifact
> Info stuff
> >> (just go to the main page) it will load
> everything.
> >
> > That's a great idea! I'll give it a try.
> >
> > My concern is with simple methods using IDs as
> identifiers. Let's say an accounting method creates a
> Map of invoices that need some kind of reconciling done on
> them. Each invoice ID is a Map key. A high volume user might
> have 10,000 invoices, so 10,000 expressions are generated
> and kept in the cache. Then in another simple method, orders
> are analyzed for backordered items and the same approach is
> used. There are 10,000 orders so another 10,000 expressions
> are created and cached. There is no limit to how many places
> and how many times this happens. I foresee a serious
> problem.
>
> Well, that would be a problem. Previously the expression
> evaluation cached the interpreted code based only on the
> straight text from the file, so no IDs unless they were
> hard-coded.
>
> Are you saying that in the UEL implementation it does one
> (inner) expansion and then parses the result, and caches
> that? In other words, there is no support for nested
> expressions?
>
> Ouch. I don't think we can get around that as a
> limitation... either we'll have to somehow get nested
> expressions working, or just stop using nested expressions
> now that we have alternatives in UEL and we really don't
> need them any more. My vote would be for the second option,
> BTW... much cleaner and may actually be easier.
I just ran some tests and discovered that my concerns are unfounded. Sorry for
the false alarm.
You are correct that we don't need nested expressions anymore. One thing to
note is that nested expressions incur a serious performance penalty because the
expression is being evaluated more than once. I agree that we should stop using
them.
-Adrian
