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

cython performance hints #1655

Open
heinezen opened this issue May 27, 2024 · 0 comments
Open

cython performance hints #1655

heinezen opened this issue May 27, 2024 · 0 comments
Labels
code quality Does not alter behavior, but beauty of our code improvement Enhancement of an existing component lang: cython Implemented using Cython code

Comments

@heinezen
Copy link
Member

heinezen commented May 27, 2024

When building openage, cython prints performance hints that we may want to resolve or disable.

openage/cppinterface/exctranslate_tests.pyx

performance hint: openage/cppinterface/exctranslate_tests.pyx:25:5: Exception check on 'call_cpp_thrower' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'call_cpp_thrower' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'call_cpp_thrower' to allow an error code to be returned.
performance hint: openage/cppinterface/exctranslate_tests.pyx:117:5: Exception check on 'py_exc_raiser' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'py_exc_raiser' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'py_exc_raiser' to allow an error code to be returned.
performance hint: openage/cppinterface/exctranslate_tests.pyx:125:5: Exception check on 'bounce_call' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'bounce_call' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'bounce_call' to allow an error code to be returned.

openage/cppinterface/pyobject.pyx

performance hint: openage/cppinterface/pyobject.pyx:68:5: Exception check on 'str_impl' will always require the GIL to be acquired. Declare 'str_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/cppinterface/pyobject.pyx:72:5: Exception check on 'repr_impl' will always require the GIL to be acquired. Declare 'repr_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/cppinterface/pyobject.pyx:76:5: Exception check on 'bytes_impl' will always require the GIL to be acquired. Declare 'bytes_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/cppinterface/pyobject.pyx:88:5: Exception check on 'call0_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'call0_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'call0_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:93:5: Exception check on 'calln_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'calln_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'calln_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:109:5: Exception check on 'getattr_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'getattr_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'getattr_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:114:5: Exception check on 'setattr_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'setattr_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'setattr_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:135:5: Exception check on 'dir_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'dir_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'dir_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:144:5: Exception check on 'exec_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'exec_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'exec_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:148:5: Exception check on 'eval_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'eval_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'eval_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:153:5: Exception check on 'get_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'get_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'get_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:162:5: Exception check on 'type_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'type_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'type_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:167:5: Exception check on 'modulename_impl' will always require the GIL to be acquired. Declare 'modulename_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/cppinterface/pyobject.pyx:171:5: Exception check on 'classname_impl' will always require the GIL to be acquired. Declare 'classname_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/cppinterface/pyobject.pyx:177:5: Exception check on 'builtin_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'builtin_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'builtin_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:182:5: Exception check on 'import_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'import_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'import_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:187:5: Exception check on 'createstr_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'createstr_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'createstr_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:192:5: Exception check on 'createbytes_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'createbytes_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'createbytes_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:197:5: Exception check on 'createint_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'createint_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'createint_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:202:5: Exception check on 'createdict_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'createdict_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'createdict_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/pyobject.pyx:207:5: Exception check on 'createlist_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'createlist_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'createlist_impl' to allow an error code to be returned.
performance hint: openage/cppinterface/exctranslate.pyx:128:5: Exception check on 'raise_cpp_error' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'raise_cpp_error' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'raise_cpp_error' to allow an error code to be returned.
performance hint: openage/cppinterface/exctranslate.pyx:157:5: Exception check on 'raise_cpp_pyexception' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'raise_cpp_pyexception' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'raise_cpp_pyexception' to allow an error code to be returned.
performance hint: openage/cppinterface/exctranslate.pyx:175:5: Exception check on 'describe_exception' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'describe_exception' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'describe_exception' to allow an error code to be returned.
performance hint: openage/cppinterface/exctranslate.pyx:247:5: Exception check on 'pyexception_bt_get_symbols_impl' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'pyexception_bt_get_symbols_impl' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'pyexception_bt_get_symbols_impl' to allow an error code to be returned.
[23/32] Cythonizing openage/main/main_cpp.pyx
performance hint: openage/cvar/cvar.pyx:22:5: Exception check on 'cy_load_config_file' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'cy_load_config_file' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'cy_load_config_file' to allow an error code to be returned.

openage/util/filelike/cpp.pyx

performance hint: openage/util/filelike/cpp.pyx:158:5: Exception check on 'file_read' will always require the GIL to be acquired. Declare 'file_read' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/util/filelike/cpp.pyx:173:5: Exception check on 'file_write' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'file_write' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'file_write' to allow an error code to be returned.
performance hint: openage/util/filelike/cpp.pyx:181:5: Exception check on 'file_seek' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'file_seek' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'file_seek' to allow an error code to be returned.
performance hint: openage/util/filelike/cpp.pyx:194:5: Exception check on 'file_close' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'file_close' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'file_close' to allow an error code to be returned.
performance hint: openage/util/filelike/cpp.pyx:198:5: Exception check on 'file_flush' will always require the GIL to be acquired.
Possible solutions:
        1. Declare 'file_flush' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
        2. Use an 'int' return type on 'file_flush' to allow an error code to be returned.
performance hint: openage/util/fslike/cpp.pyx:239:5: Exception check on 'fs_list' will always require the GIL to be acquired. Declare 'fs_list' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/util/fslike/cpp.pyx:289:5: Exception check on 'fs_open_r' will always require the GIL to be acquired. Declare 'fs_open_r' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/util/fslike/cpp.pyx:295:5: Exception check on 'fs_open_w' will always require the GIL to be acquired. Declare 'fs_open_w' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/util/fslike/cpp.pyx:301:5: Exception check on 'fs_open_rw' will always require the GIL to be acquired. Declare 'fs_open_rw' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/util/fslike/cpp.pyx:307:5: Exception check on 'fs_open_a' will always require the GIL to be acquired. Declare 'fs_open_a' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/util/fslike/cpp.pyx:313:5: Exception check on 'fs_open_ar' will always require the GIL to be acquired. Declare 'fs_open_ar' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/util/fslike/cpp.pyx:319:5: Exception check on 'fs_resolve_r' will always require the GIL to be acquired. Declare 'fs_resolve_r' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/util/fslike/cpp.pyx:327:5: Exception check on 'fs_resolve_w' will always require the GIL to be acquired. Declare 'fs_resolve_w' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: openage/util/fslike/cpp.pyx:335:5: Exception check on 'fs_get_native_path' will always require the GIL to be acquired. Declare 'fs_get_native_path' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
@heinezen heinezen added improvement Enhancement of an existing component code quality Does not alter behavior, but beauty of our code lang: cython Implemented using Cython code labels May 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code quality Does not alter behavior, but beauty of our code improvement Enhancement of an existing component lang: cython Implemented using Cython code
Projects
Development

No branches or pull requests

1 participant