Skip to content
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

build runs very slow when export numbers are high #8447

Closed
waterlike86 opened this issue Apr 16, 2019 · 6 comments
Closed

build runs very slow when export numbers are high #8447

waterlike86 opened this issue Apr 16, 2019 · 6 comments
Labels

Comments

@waterlike86
Copy link
Contributor

i found that the function function_tables_and_exports takes very long when the export numbers are high.
most of the time is spent in function check_all_implemented to check for missing functions.
in our project where the number of exports is > 70000 this function can easily take up to 15 mins or more

maybe we can make this check parallel? and possibly improve the execution logic.

@waterlike86
Copy link
Contributor Author

cc @kripken @awtcode

@kripken
Copy link
Member

kripken commented Apr 16, 2019

I'd try to speed this up with early exiting in is_already_implemented - avoiding the string search might help. Or perhaps we should do a single search up front for all patterns function X, and then the check can be much faster using that.

@waterlike86
Copy link
Contributor Author

i first subtracted the 2 arrays, remove all which are already in all_implemented and looped through the rest to perform the string search. this still took half the time which is close to 10mins.

1 more question, do we need this check in dynamic linking? perhaps its not that useful when its a side/main module?

@awtcode
Copy link
Contributor

awtcode commented Apr 17, 2019

One suggestion is to copy the larger array into a map so that all the accesses will be in constant time and instead of looping thru the arrays and logging the elements one by one, just store all of them into a string and log them at one go.

@waterlike86
Copy link
Contributor Author

@kripken i opened a PR which helps with this

@stale
Copy link

stale bot commented Apr 16, 2020

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Apr 16, 2020
@stale stale bot closed this as completed Apr 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants