-
-
Notifications
You must be signed in to change notification settings - Fork 922
chore: Move AvmString code into a new crate #21629
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
base: master
Are you sure you want to change the base?
Conversation
The idea of separating avm string to its own crate sounds good, but I'd say we 100% have to do benchmarks and make sure it doesn't affect performance negatively. |
71ce3dd
to
b2d8c7c
Compare
I don't see any performance impact from this change (on microbenchmarks for string indexing and concatenation) and I see a ~2 second speedup in recompiling core, so I think this is okay on the performance side. |
b2d8c7c
to
491d087
Compare
491d087
to
71c1804
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but this is a significant architectural change (especially if we expect ruffle_common
to grow in the future, e.g. by moving HasPrefixField
there) so a second opinion would be best.
pub use common::CommonStrings; | ||
pub use context::{HasStringContext, StringContext}; | ||
pub use interner::{AvmAtom, AvmStringInterner}; | ||
use ruffle_wstr::{from_utf8, WStr, WString}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd keep the other reexports (now from ruffle_common::avm_string
), to avoid having to update the use
statements everywhere else.
In the future, we can move other types shared across the AVMs and core player to this crate
71c1804
to
0b379ec
Compare
This should make separating AVM2 from core slightly easier in the future, if we ever do it. This also reduces compile times slightly, especially when re-building after modifying
core
code.The only downside of this that I can see is that without LTO, some functions from
avm_string
might not get inlined incore
. However, those functions don't seem to be very hot, so this is probably fine.