I wouldn’t say that it is inactive… You got a reply pointing to an upstream bug in less than an hour, also there has been a release 2 days ago, which should also tackle the rustup/multirust issue as far as I can see.
NobbZ
OvermindDL1
That is a good sign, however that upstream bug is another rust library for the low-level erlang API, and it’s had no response to its issue report for over a week. 
EDIT: Heh, I just noticed that the person that posted the link is the author of the other library, yet no updates over there for a long time. 
1
NobbZ
OTP 19 is only 2 weeks old, give them some time to do necessary research and adjustements and use 18 until then.
1
OvermindDL1
Eh except I’ve been using 19 for well before its release, at work I needed something that was new in it (forgot what it was now…), so I’ve no choice.
1
nathanl
It’s a bit more complex. There is a cache hierarchy…
Thanks - as you can tell, I’m not very knowledgable about hardware caches. 
You should remember how erlang and elixir work. If you pass some data, the data is copied around. This is done to isolate the data from the execution.
Yes - usually. Except that binaries greater than 64 bytes in size are shared by all processes and refcounted, and those larger than 512 (in my tests) are not combined when calling writev, probably based on ERL_SMALL_IO_BIN_LIMIT (according to Elixir RAM and the Template of Doom – Evan Miller)
If you are really really interested in having full control of your data layout
I’m not. I have simply been trying to understand a stated benefit of Phoenix.
0
nathanl
I’ve exchanged emails with José Valim and Chris McCord about this. It sounds like the original statement in “Programming Phoenix” may have been based on some assumptions rather than specific measurements.
0
nathanl
Update: I just learned about perf stat -e L1-dcache-load-misses from Julia Evans and wanted to try perf stat -e L1-dcache-load-misses -p $(pgrep beam) on Phoenix, but I’m on OS X and perf is Linux-only.
I tried anyway, running Phoenix under a Linux VM in Vagrant, but perf told me that L1-dtrace-load-misses was not supported (for my CPU?), and I’m out of my depth there. But if anyone cares to try this on Linux hardware and gets results, I’d be interested.
1
nathanl
I took another shot at this: I set up a Linux box on linode.com, got Phoenix running on it, and ran /perf stat -e L1-dcache-load-misses -p $(pgrep beam). That does show me data like this:
Performance counter stats for process id '17462':
1,714 L1-dcache-load-misses
1.399432582 seconds time elapsed
However, that’s all noise - it’s what I see after running the command above, waiting a second or so, and pressing control + c, without making any requests to the app. It appears that there are more than 1k cache misses per second for that process even if I’m not asking it to do anything.
I don’t see a good way to separate the noise from the signal here. If I could, I could compare the performance of my two Phoenix endpoints. But it appears I’m stuck again.
(Probably nobody cares about this thread anymore but me, but having documented this much, I thought I might as well post an update.)
2
andre1sk
You are runing on a box that depending on the plan might be runing several hundred VMs that’s not exactly a good enviroment for gathering CPU cache stats
3
nathanl
You are runing on a box that depending on the plan might be runing several hundred VMs that’s not exactly a good enviroment for gathering CPU cache stats
True. I thought that providing perf with the process id would screen out the noise, but maybe not.
I guess if I really want to test this, I need to set up a dedicated physical machine. Maybe I’ll get around to trying that eventually.
1