You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Heap allocating boxes for integers, doubles, and chars seems very redundant when it should be cheaper to just copy around the box itself. This needs to be properly investigated.
Actually, it should be possible to simply copy the purs_any_t everywhere and only take pointers to it for internal functions if needed. We can probably use a smaller type for the tag, making the cost of copying this thing around negligible (tag + union)?
I'd love feedback on this. I just set up the inlineCommonValues optimization pass and added as a first example inlining integer negation, but this optimization looks far from optimal:
Essentially we have to dereference a pointer, allocate new heap memory, initialize it, and copy the now negated value over. A sizeof (purs_any_t) on my machine yields 24, whereas a pointer to one is only 8. I think we should stop heap allocating the boxes and just copy the structs around. It will also take pressure off the gc. At this point, however, it would have a large knock on effect into the existing libraries, so we should develop this on a branch and attempt to get it merged after we see #12 passing with the current approach, I'd say.
Heap allocating boxes for integers, doubles, and chars seems very redundant when it should be cheaper to just copy around the box itself. This needs to be properly investigated.
I just found myself writing this FFI code:
The text was updated successfully, but these errors were encountered: