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

Optimize object filename from source #14200

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

bruchar1
Copy link
Member

Inspired by #14103, I did some profiling on my project generation, and added some optimisations. The most significant is the _get_file_from_list() that cut generation time from 60 sec to 45 sec on my project.

There was a missing parameter in one call.
This was caused by b95e177
@bruchar1 bruchar1 force-pushed the optimize-object-filename-from-source branch from 68349f1 to a49b268 Compare January 29, 2025 12:43
@bruchar1
Copy link
Member Author

I don't understand the mypy failure here...

@dnicolodi
Copy link
Member

dnicolodi commented Jan 29, 2025

I don't understand the mypy failure here...

It seems that mypy does not know about the dir_fd and follow_symlinks of shutil.chown. I think it is a mypy bug, or better a bug of the typing stubs for the standard library.

EDIT: actually the stubs are right in typeshed, but mypy does not grok the version check just above. The same applies for pylint as indicated in the comment. I think adding a local mypy ignore annotation is the best way to deal with this.

Comment on lines 835 to 837
parts = Path(fname).parts
if mesonlib.is_windows():
fname = fname.replace('\\', '/')
parts = fname.split('/')
Copy link
Member

Choose a reason for hiding this comment

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

This function is already cached by fname, so this change will only ever affect one call per filename that gets canonicalized. Is Path() actually showing up in profiling here?

Copy link
Member Author

Choose a reason for hiding this comment

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

In its performance improvement tracking issue, @bonzini was mentioning speed up object_filename_from_source . The canonicalize_filename call was using a significant time in that function, and pathlib stuff was the culprit.

That being said, object_filename_from_source is not really a hotpath when generating my project. I could drop that commit if you think it doesn't worth it.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not saying that object_filename_from_source isn't slow! I'm just trying to understand whether caching it was enough to remove it as a hotpath. If it isn't a hotpath, then using Path().parts is a bit more convenient due to avoiding platform-specific if/else.

That discussion didn't even mention pathlib being the cause. I would personally have assumed that hashlib.sha1() is the cause, if I had to take a wild guess, though.

Copy link
Member Author

Choose a reason for hiding this comment

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

When profiling my project, about half of the time in object_filename_from_source is spent in relpath, and maybe 20% in canonicalize_filename. In canonicalize_filename, half of the time is spent in Path.parts, and 20% in Path.__init__. I'm not sure I ever hit the sha1 call here.

Globally, I got 670 call to canonicalize_filename, and 27 calls to sha1, and time spent in sha1 is almost nothing.

def _get_trials_from_pattern(cls, pattern: str, directory: str, libname: str) -> T.List[Path]:
f = Path(directory) / pattern.format(libname)
def _get_trials_from_pattern(cls, pattern: str, directory: str, libname: str) -> T.List[str]:
f = os.path.join(directory, pattern.format(libname))
Copy link
Member

Choose a reason for hiding this comment

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

This change overall looks good. There was never any real reason to use pathlib here especially since we spent a lot of time transforming strings into Path objects just to reconvert them back into strings.

@bonzini
Copy link
Collaborator

bonzini commented Jan 29, 2025

Note that #14109 added caching for canonicalize_filename, is it still a hot path? (The changes are all very nice anyway).

@bruchar1 bruchar1 force-pushed the optimize-object-filename-from-source branch from a49b268 to 2f8ea40 Compare January 29, 2025 18:14
@bruchar1
Copy link
Member Author

Note that #14109 added caching for canonicalize_filename, is it still a hot path? (The changes are all very nice anyway).

With this improvement, I observe a 10x speedup on the canonicalize_filename function. In my project, around 25% of the call to that function are cached. Therefore, both help, but optimization contributes more to the speedup.

For instance, profiling my project, the cumulative time for canonicalize_filename are:

  • no cache, no optim: 25.5 ms
  • cache, no optim: 20.1 ms
  • no cache, optim: 3.4 ms
  • cache, optim: 2.8 ms

@bonzini bonzini added this to the 1.8 milestone Jan 30, 2025
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.

5 participants