-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
recursive implementation of the tuple
is very inefficient
#3307
Comments
@volodya-lombrozo thanks for the report, here is a feedback: Problems
I would recommend including expected versus actual results when executing the command, to identify where the discrepancy lies. Please fix the bug report in order it to get resolved faster. |
@yegor256 @maxonfjvipon Please, take a look. This problem happens rather often and it influences Examples: |
@maxonfjvipon please, help us here |
@volodya-lombrozo @yegor256 in the provided log processed XMIR is printed and it has 379 nested
(Stars on line 314, ends on line 690) I see two scenarios:
we'll get:
Since here we use EO and XMIR as IR - we don't need to run it, which means we can do it. The code's much more readable, does not contain so many nested object and should not cause unpredictable troubles related to large nesting. WDYT? |
@maxonfjvipon To be honest, I like the both suggestions. However, adding "mysterious" atoms might cause some problems in the future as well. I would suggest to try the first point first, then if we don't find anything satisfiable (or it will take significant time,) we can just go by the second path. What do you think? |
@maxonfjvipon Friendly reminder |
@volodya-lombrozo here I found the info that such behaviour is related to insufficient stack size (which is 256M now). |
@maxonfjvipon Thanks. I will try to increase stack size for now. |
@volodya-lombrozo I believe, it's fixed? |
@yegor256 How? The problem is still here, as far as I understand. @maxonfjvipon Please, correct me, if I'm wrong. If we have a |
@maxonfjvipon we may think about a more optimal implementation of |
@yegor256 we definitely should |
tuple
is very inefficient
I am facing a problem with printing PHI expressions. I encountered the following exception when I ran
eo-maven-plugin:0.39.0:xmir-to-phi
:As you can see, the
set-locators.xsl
transformation uses too many nested function calls. This problem usually happens on Windows OS, and it's flaky. I have attached the full log below.build.log
The text was updated successfully, but these errors were encountered: