Skip to content

Use os.execv when we only running clang to compile. NFC#20884

Merged
sbc100 merged 1 commit into
emscripten-core:mainfrom
sbc100:use_exec
Dec 13, 2023
Merged

Use os.execv when we only running clang to compile. NFC#20884
sbc100 merged 1 commit into
emscripten-core:mainfrom
sbc100:use_exec

Conversation

@sbc100
Copy link
Copy Markdown
Collaborator

@sbc100 sbc100 commented Dec 8, 2023

This saves about 10ms of overhead on my linux machine which is about 10% of the overall overhead or emcc.py over base clang.

It will also save on memory since python no longer needs to be resident at the same time as clang.

@sbc100 sbc100 force-pushed the use_exec branch 2 times, most recently from 747eb01 to df1abf8 Compare December 8, 2023 20:57
@sbc100 sbc100 requested review from RReverser and kripken December 8, 2023 20:57
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 8, 2023
We had this rather strange (I imagine completely unused) feature where
is emscripten is passed a concrete path to a shared library file (e.g.
/path/to/libfoo.so) and it could determine that the shared library was
not indented for emscripten then it would instead search the library
for other things called `libfoo` that might work.

This seems too magical at best and harmful/confusing a worst.

The presence of this feature is blocking the way for some internal
optimizations and refactorings (e.g. emscripten-core#20884)
Comment thread emcc.py


def exec_subprocess_and_exit(cmd):
if utils.WINDOWS:
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is necessary - Python has execv on Windows too, it just can't load cmd into the same process, so it falls back to the slower path automatically.

Might be cleaner to just use the same API on both platforms.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I didnt know they had emulation. Thats odd.

It looks like there are maybe some issues with the emulation though: https://bugs.python.org/issue19066.. those seems like fairly major issues, but I guess it would be easy enough to detect and our tests would fail I believe.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh huh, if there are issues, it's probably not worth it. I thought it would be cleaner and easier to just use single API, but if it doesn't fall back to whatever subprocess does, that's a moot point.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although that one is from 2014 and was closed, so maybe not a problem anymore?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I have to land a few other changes before this one (e.g. #20886), but if the tests all pass with execv on windows then I'll go with that option.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like you left this in?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I figured we can try and take it out after and see what CI says. I guess I could have tried it right away..

sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 8, 2023
We had this rather strange (I imagine completely unused) feature where
is emscripten is passed a concrete path to a shared library file (e.g.
/path/to/libfoo.so) and it could determine that the shared library was
not indented for emscripten then it would instead search the library
for other things called `libfoo` that might work.

This seems too magical at best and harmful/confusing a worst.

The presence of this feature is blocking the way for some internal
optimizations and refactorings (e.g. emscripten-core#20884)
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 8, 2023
We had this rather strange (I imagine completely unused) feature where
is emscripten is passed a concrete path to a shared library file (e.g.
/path/to/libfoo.so) and it could determine that the shared library was
not indented for emscripten then it would instead search the library
for other things called `libfoo` that might work.

This seems too magical at best and harmful/confusing a worst.

The presence of this feature is blocking the way for some internal
optimizations and refactorings (e.g. emscripten-core#20884)
Comment thread emcc.py Outdated
Comment thread emcc.py Outdated
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 11, 2023
We had this rather strange (I imagine completely unused) feature where
is emscripten is passed a concrete path to a shared library file (e.g.
/path/to/libfoo.so) and it could determine that the shared library was
not indented for emscripten then it would instead search the library
for other things called `libfoo` that might work.

This seems too magical at best and harmful/confusing a worst.

The presence of this feature is blocking the way for some internal
optimizations and refactorings (e.g. emscripten-core#20884)
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 11, 2023
We had this rather strange (I imagine completely unused) feature where
is emscripten is passed a concrete path to a shared library file (e.g.
/path/to/libfoo.so) and it could determine that the shared library was
not indented for emscripten then it would instead search the library
for other things called `libfoo` that might work.

This seems too magical at best and harmful/confusing a worst.

The presence of this feature is blocking the way for some internal
optimizations and refactorings (e.g. emscripten-core#20884)
sbc100 added a commit that referenced this pull request Dec 12, 2023
We had this rather strange (I imagine completely unused) feature where
is emscripten is passed a concrete path to a shared library file (e.g.
/path/to/libfoo.so) and it could determine that the shared library was
not indented for emscripten then it would instead search the library
for other things called `libfoo` that might work.

This seems too magical at best and harmful/confusing a worst.

The presence of this feature is blocking the way for some internal
optimizations and refactorings (e.g. #20884)
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 12, 2023
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 12, 2023
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 12, 2023
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 12, 2023
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 12, 2023
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 12, 2023
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 12, 2023
sbc100 added a commit that referenced this pull request Dec 12, 2023
This saves about 10ms of overhead on my linux machine which is about 10%
of the overall overhead or emcc.py over base clang.

It will also save on memory since python no longer needs to be resident
at the same time as clang.
@sbc100 sbc100 enabled auto-merge (squash) December 13, 2023 00:10
@sbc100 sbc100 disabled auto-merge December 13, 2023 00:33
@sbc100 sbc100 merged commit fb19437 into emscripten-core:main Dec 13, 2023
@sbc100 sbc100 deleted the use_exec branch December 13, 2023 00:33
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 13, 2023
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 13, 2023
sbc100 added a commit to sbc100/emscripten that referenced this pull request Dec 13, 2023
sbc100 added a commit that referenced this pull request Dec 13, 2023
sbc100 added a commit to sbc100/emscripten that referenced this pull request Jan 3, 2025
We had this rather strange (I imagine completely unused) feature where
is emscripten is passed a concrete path to a shared library file (e.g.
/path/to/libfoo.so) and it could determine that the shared library was
not indented for emscripten then it would instead search the library
for other things called `libfoo` that might work.

This seems too magical at best and harmful/confusing a worst.

The presence of this feature is blocking the way for some internal
optimizations and refactorings (e.g. emscripten-core#20884)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants