-
Notifications
You must be signed in to change notification settings - Fork 3k
Refactor memap for speed #5125
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
Refactor memap for speed #5125
Conversation
@MarceloSalazar Could you take a look? |
Adding needs work for parsing tests. |
GCC PerformanceSpeedup: 10.86 Before
After
|
Arm Compiler 5/6 performanceSpeedup: 14.67 Before
After
|
IAR PerformanceSpeedup: 11.38 Before
After
|
The speedup is great! :) |
@MarceloSalazar That was part of the cause of testing being so horribly slow on some people's machines. Check #5124. I'm going to add a bit of detail as to why this is a problem. |
Only for tests. |
This is the intended behavior of mbed OS tests. |
Could we add/concatenate the 'mbed-os' text, so the output is consistent with the apps' output as well? In the end, tests as also some kind of apps. |
To some degree, this PR is already consistent between the apps and tests; As this PR stands, the output is always relative to the root of the app's containing directory. You are suggesting that it "Look the same" which is a different form of consistency. |
FYI, I'm going to be completely reworking this PR. There's yet another speedup to take advantage of: the resources object already contains all of the information that we could get from scanning. So let's not be silly and just use that. |
Hmmmm... bad rebase. Just a sec. |
2b6d4c6
to
7fe7eee
Compare
There we go; that should be a clean history. |
Instead of scanning. Is a 8ms/15% speedup.
We just don't care if we don't know where they go
07687aa
to
6d135c2
Compare
Now we don't have to scan! This is a 20% speed improvement
9375cb6
to
fdd4ae3
Compare
Second round here: IAR is now down to 60ms, and ARM down to 55ms. No files were scanned. |
What is the current status of this patch? Any more reviews from the referenced ppl here? |
From the technical point of view, I'll let others comment, but the figures speak for themselves :) From the usability point of view, I still believe we need consistency and generate output that looks the same (IMO tests are basically apps with main components: mbed-os, C/C++ library, and the app/tests itself). Also, there are consumers for this output that would like consistency, either CI systems that need to keep track of this information or others working on UI tools to display/analyze it. |
@0xc0170 I have to write a test for GCC parsing. Then we can run it through a morph test. |
@MarceloSalazar I have to say that I don't think it's "consistent" to do path mangling for only tests. As a user, If I saw a
I think this is the point of contention. They are built that way (to some extent) but they are not structured that way in the filesystem. Like I said in another comment, I think the form of consistency I am suggesting is good for users, as it can help them discover how tests are build and structured and does not hide either of those aspects of test. @sg- Could you share your opinion? |
if I created a folder test and imported mbed-os into it and then ran mbed test would that solve the problem? |
That would create a build error. You would have 2 of each Mbed OS symbol. If you also added a |
It's just not used anymore
/morph test |
@adbridge @MarceloSalazar Please review again |
Looks good! :) |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
Improves performance by 10-15x on my machine. See below for individual compiler comparisons.
Resolves #4976
Resolves #5124
Resolves #5127
Todo:
Malformed input...
output from GCC