2015-02-23 16:36 GMT+01:00 Eliot Miranda <[email protected]>: > Hi Thierry, > > there's an unadvertised primitive called Context>>#xRay (or > ContextPart>>#xRay) that answers these questions for tests. I'm away from > the system right now but I'll get you the source soon. Also, the limit on > jutting methods, 60 literals, is a default. There's a command line option > -maxcoglits (IIRC) that you can change. >
Thanks Eliot! It's helping a lot to guide me, even if I have to work at the ast level and, as a result, I estimate the number of literals in the bytecode by counting the number of literal nodes in the AST, with the approximation that ~100 literal nodes will make it under the limit. Making it under the limit shaves 30% of the execution time of a parse with SmaCC. And it avoids the too long methods as a side benefit. I would dream of having precise ways of estimating things like that on the AST. It's interesting to hit those "I'd like to be able to predict the performance of that piece of code" issues. Thierry > > Eliot (phone) > > On Feb 23, 2015, at 5:05 AM, Thierry Goubier <[email protected]> > wrote: > > > Hi All, > > > > anybody knows how to check if a method is jitted or not? > > > > I remember (maybe wrongly) that the Jit in Cog has a configurable limit > on the number of bytecodes for a method to be jitted or not; I'm looking > into the performance of generated code where I can, more or less, control > the length of methods (SmaCC) and I'd like to find the optimum point. > > > > Thanks, > > > > Thierry > >
