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

IE-0008: Faster memory allocation #8

Merged
merged 1 commit into from
Aug 1, 2022
Merged

Conversation

curiousdannii
Copy link
Collaborator

  • Proposal: IE-0008
  • Authors: Dannii Willis
  • Language feature name: None
  • Status: Draft
  • Related proposals: None
  • Implementation: None

Summary

Faster runtime access to flexibly-sized data like texts and lists.

@curiousdannii curiousdannii added the formal-proposal A formal proposal that has been accepted for consideration by the core Inform team label Aug 1, 2022
@ganelson ganelson merged commit 79d96b3 into main Aug 1, 2022
@curiousdannii curiousdannii deleted the ie-0008-faster-malloc branch August 1, 2022 13:37
@erkyrath
Copy link
Collaborator

erkyrath commented Aug 1, 2022

Glulx is very reliably implemented and we can have confidence that its malloc opcode will be efficient.

Optimist :)

I am reasonably confident that the malloc opcode is implemented reliably. But I suspect there will be a round of patching it up to be efficient enough for widespread use.

@curiousdannii
Copy link
Collaborator Author

curiousdannii commented Aug 1, 2022

Even if it's quite unperformant, it's going to be better than Inform implementing its own malloc system as it does now!

I had originally suggested inlining most of the calls to BlkValueRead/BlkValueWrite, but Graham would prefer to keep them, and hinted that Inter might be able to handle inlining these calls. That would be fantastic!

Maybe one way to try to help keep things working in Z-Code would be to be more particular about how big a block is allocated for lists/texts? Ie, never over-allocate to begin with, only increase to the next smallest size block, and immediately decrease in size if the required length ever drops. If I'm reading the code correctly, the current list template never shrinks lists? So a change like that might go a long way to preventing unnecessary fragmentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
formal-proposal A formal proposal that has been accepted for consideration by the core Inform team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants