Dear Tomas, Inaki and the rest of R-devel team,
thank you for your explainations and suggestions. I talked with gEcon
development team and we decided to change our implementation along the
lines you suggested.
Best regards,
Karol Podemski
pt., 17 sie 2018 o 13:38 Tomas Kalibera
napisał(a):
>
Dear Karol,
I don't understand the models behind these function, but I can tell that
the code generated is very inefficient. The AST interpreter will be very
inefficient performing each scalar computation with all boxing,
allocations, function calls. The byte-code compiler removes some of the
Karol,
If I understood correctly, functions like "foo" are automatically
generated by gEcon's model parser. For such a long function, and
depending on how many times you need to call it, it may make more
sense to generate C++ code instead (including the 'for' loop). Then
you can use Rcpp::sourceCp
Dear Thomas,
thank you for prompt response and taking interest in this issue. I really
appreciate your compiler project and efficiency gains in usual case. I am
aware of limitations of interpreted languages too and because of that even
when writing my first mail I had a hunch that it is not that e
Dear Karol,
thank you for the report. I can reproduce that the function from you
example takes very long to compile and I can see where most time is
spent. The compiler is itself written in R and requires a lot of
resources for large functions (foo() has over 16,000 lines of code,
nearly 1 mil
Dear R team,
I am a co-author and maintainer of one of R packages distributed by R-forge
(gEcon). One of gEcon package users found a strange behaviour of package (R
froze for couple of minutes) and reported it to me. I traced the strange
behaviour to compiler package. I attach short demonstration
