IT’S ABOUT DAN TIME
Of course! The rate hikes had been working to reduce M2 growth, but once they hinted at a cut, the retail printing took off (retail loans create money from nothing) and inflation came back.
Updated M2 trend line brings us to the long-term trend (blue line) around September.
It’s not just money. It is money that is just.
WebAssembly (WASM) is a subset of JavaScript to which compiled languages can target. An increasing number of libraries and programs are available this way. For example, there’s an ffmpeg port that lets you transcode video in a WebWorker using WASM.
In JavaScript, the basic Array type is dynamic (no permanently fixed size, no fixed type). Typed arrays (Float32Array etc.) are statically sized at allocation time and only contain the specified type.
If you know how many items your dynamic Array is going to hold, you can pass that length into the constructor.
const myArray = new Array(100);
But this won’t stop you from assigning off the end of the array if you so choose:
myArray[999] = ‘foo’; // 👍
In the browser, you can make pre-allocated, fixed-length, typed arrays. For example Float32Array, Uint8Array etc. These are quite fast to access once created since no new memory is used.
They’re probably less useful in the context of a Nostr client which deals almost exclusively in string data, but yes, if you can use them it’s a great way to go.
I'm totally new to programming for the browser but I'm starting to appreciate the challenge (actually quite a lot more difficult than systems level programming in many ways).
The main gotchya I'm hitting is that the browser is built around a single threaded event loop. It alternates between doing computation, and updating the page. When a page feels all clunky and slow it's (probably) because the computation part is taking a long time and blocking all the other updates waiting to be rendered on the page.
But it turns out there are these things called web workers, which allow computation to be done "on the side" and not block anything.
If I can manage to get all the relay/subscription and event computation done within web workers, this should make the user experience much smoother and generally improve the performance of the nostrocket client.
I'm experimenting here if anyone wants to follow the progress: https://github.com/nostrocket/buttr
It really depends on the situation. Browser performance has a lot of facets.
I recommend using a profiler like the one built into Chrome. It’ll tell you what’s taking all the time.
Generally, in my experience, it’s not computation that’s the issue. More likely memory. If your code is making lots of small objects, iterating them and deleting, these operations tend to dominate the non-DOM time.
What’s the gist?
Saying that #Bitcoin miners “validate” transactions is like saying that farmers breathe air.
Sure, they technically do it, just like everyone else. But this is not their value proposition.
$10M BY HALVING STILL IN PLAY
nostr:note1cr4r6x57hcun7ataxx5c8fegghg8effedg9n04ye2wn29g8469cslwnmr8
#100pushups a day until #Bitcoin $100k
Day 019: 2024-04-09 - 5x20
In between 5x5 back squats. Leg day, let’s go! 🦵
I’m optimistic. Information travels too fast to keep people in the dark about the one tool that will save them.
#100pushups a day until #Bitcoin $100k.
Day 018: 2024-04-08 - 20, 20, 20, 20, 20
