Maurício Szabo

Performance optimizations in Reagent – part 2

Have I mentioned that it’s a nightmare to install React Devtools in Electron? Turns out, it’s worth it. But it’s still a pain. If you want to try, you’ll need to first install the extension in a chrome-based browser (like Brave, the one I use) and then install it by code. At Chlorine, what I did was to copy the whole extension folder to a devtools directory and then changed the script to load electron to the script below (see the BrowserWindow.addDevToolsExtension):

const path = require('path')
const {app, BrowserWindow} = require('electron')

app.on('ready', () => {
  let browser = new BrowserWindow({
    width: 900, height: 600,
    webPreferences: {nodeIntegration: true}})
  browser.loadURL(path.join('file://', __dirname, '/index.html'))

  BrowserWindow.addDevToolsExtension('./devtools')
})

Originally, the React Devtools was installed at ~/.config/BraveSoftware/Brave-Browser/Default/Extensions/fmkadmapgofadopljbjfkapdkoienihi/4.21.0_0 (tilde is my home folder). If you’re trying to install on Atom editor, you’ll have to open developer tools and issue the following script:

r = require('remote')
r.BrowserWindow.addDevToolsExtension('./devtools') // or the right directory

This command will fail, but somehow when you reload Atom, the React Devtools will be there. There’s only one feature that I use – highlight which elements were updated. And that’s where our performance tuning starts again.
(more…)

By Maurício Szabo, ago

The magical wonders of programming with pure data

I’ll start with a disclaimer – if you’re developing in ClojureScript because of performance, you’re doing the wrong thing. Although a Clojure code can be really close to Java performance, ClojureScript simply can’t match JS performance – specially because in Javascript, the fundamental data structures like arrays, sets, and objects are implemented in a faster language, and as of today, no “user space” data structure can get even close the “native” ones. And, let’s not forget that JS is slower than Java.

So, if you want to beat JS performance in ClojureScript, you have to make use of what ClojureScript offers you – the REPL, the fast experimentation, and the wonderful experience of programming with data. So, this is a tale of a huge performance improvement that I’m currently working in Chlorine.

Rendering EDN

In Chlorine and Clover, when you evaluate something, the result will be rendered in a tree-like way at the console. This works quite well for Clojure, because UNREPL makes structures that are too big small, and you can query for more data. So far, so good.

In ClojureScript, Clojerl, Babashka, etc, things are not so good. Big data structures will be rendered fully on the view. They can lock or crash your editor, they can occupy all your memory, etc. The reason for that is that tree structures are hard – when you’re rendering the “parent”, you don’t know what the children will be. Currently, in Chlorine, rendering (range 80000) locks my editor for 4 seconds until it calculates everything, layouts all data, etc… and I wanted to change this.

Reagent vs Helix vs React

I was always intrigued on how much performance hit I get when I use Reagent’s Hiccup data structure instead of React objects – after all, there must be some performance problems, right? After all, that’s the promise of Helix – to not pay this performance hit because you’re closer to what React wants.

So, first things first: profiling Javascript inside Electron IS A NIGHTMARE. I decided to install React Devtools extension on Electron (inside the Atom editor) but that got me into so much trouble, false-positives, wrong profiles that I ended up deciding against it and simply used the “performance” tab to do my profiling. There, I could see batching.cljs hogging my performance, so the next move was easy – move away from Reagent and use Helix.

Except… that Helix uses some macros and I ended up doing the code in React. My testcase was simple: render a vector of 80000 elements and see how it would perform, obviously without all the bells and whistles that Chlorine offers today (otherwise this experiment would be waaay longer). And that’s where things get surprising: with Reagent, I was hitting 1800ms of scripting, and about 120ms of rendering. With React… 1650ms of scripting, and about 200ms of rendering. I decided to do more benchmarks and probably because of OS caching, warm-up, or whatever, the results got even closer, with Reagent sometimes performing better than React – but still too slow.
(more…)

By Maurício Szabo, ago

Rebirth of the idea of a Hackable Code Editor

So… Atom is in zombie state. Almost everything kinda works but not 100% works so the idea of a “Hackable Text Editor for the 21st Century” is almost dead. LightTable is buried, and it was not as hackable as Atom. And there’s VSCode – a closed-source, telemetry enabled, Microsoft controlled editor based on an open-source model that’s kinda the Webkit model – you have to fork the editor and make your changes, because they control the available APIs, the way that the editor is going, etc.

So what we have now? To be honest, not much. There’s emacs and Vim/NeoVim, but these are all text-based and have both people that love them and people that hate. It’s also not that easy to make plug-ins and configurations (one you have to learn elisp, and the other you can use a mix of multiple languages like VimL, Lua, Node.JS, Python, but they all feel “out-of-place”.

Let’s try to make a new editor? Maybe that’s insanity, so let me tell you what I have in mind:
(more…)

By Maurício Szabo, ago

The state of JS in 2021

So… I recently found out that I had no space left on my SSD. When I tried to debug what was consuming my space, my projects folder were the culprit. How? I mean, I take photos, store them in RAW format, so how source code can be consuming more than my photos?

Turns out that by running rm -Rf (find -name 'node_modules'), (FISH shell) I was able to free 20gb of space!

So… let’s see how bizarre is the Javascript ecosystem in 2021.

Strangely big libraries

Sometimes, when I have to generate projects, they ask me to install yo. Yo is just a CLI to run generators – it does not include any generator. Yo occupies 89mb of space in my disk. Installing the react-webpack (manually by running npm i generator-react-webpack, because otherwise yo will try to install globally) means that your node_modules now occupies 180mb.

Let’s thing a little bit about this number: Windows XP, minimalist install without any add-on, requires 1.5gb of space. So a SINGLE GENERATOR occupies 12% of a full operating system.

So, create-react-app is more gentle – it just installs under 5.3mb. Generating a react app creates a node_modules folder with… 242mb. One of the dependencies is global-modules, that is just a single file with an if to define how to call things. It’s also only used in a single file – react-dev-utils/printHostingInstructions.js – in the folllowing code:
(more…)

By Maurício Szabo, ago

The end of an era: goodbye, GitHub

We all knew that Microsoft would destroy GitHub. Well, I hope we all knew. I knew it too, but somehow, I thought: it doesn’t matter. Maybe they’ll add some commercial features, maybe they’ll force some integration over VSCode or Visual Studio, but anyway, I didn’t think, at the time, that they’ll be able to make something really bad about it.

This ends now.

Microsoft (I’ll not use GitHub anymore here. I’ll keep GitHub for Atom, probably, but that’s how far I’m willing to go) decided that “public repos are reusable pieces of software” regardless of license, with their “Copilot” product. Yes, people are saying that’s legal, fair trade, blah blah blah. I don’t buy it, and I believe it’s only because it’s Microsoft that they are speaking like this. Every other system that inputs <copyrighted-content> and outputs <content>, when the input and output are the same “kind” (music, painting, code, poetry) needs to be aware of the original license, and that’s final. In fact, every tool that tried to do this in the past WAS victim of copyright strikes – so why Microsoft is not? In fact, there’s public code that’s not open source on Microsoft’s servers. If they are so sure that it’s not a “derivative work”, why didn’t they train their ML with private repositories? With Microsoft’s own private code? The answer is obvious – only the fool don’t want to see.

Anyway, I’ll be removing all code from Microsoft starting now. Unfortunately, there are issues to code cooperation and other things if I decide to self-host a solution, so until Gitea allows for federated content, I’ll got with Gitlab. I’ll start with Chlorine, Clover, and similar projects like REPL-Tooling, Duck-REPLed and Vision. Then, maybe I’ll start moving things on demand (after all, all code that EXIST today was slurped by Microsoft already, so why should I bother removing the damage that already was done). So, here I’ll try to document my process:
(more…)

By Maurício Szabo, ago

The power of Pathom

Most people don’t know the power of Pathom. Most people that I know of think that Pathom is about graphs.

They are wrong.

I mean, yes, in the end you’ll have a graph, with dependencies, but that’s not the point. The point of Pathom is the ability to transform your code into a soup or attributes. It’s also probably the best usage of qualified keywords for me, if not the only one that justifies the downsides (I’ll not enter in details here – just know that having to convert from qualified keywords to unqualified multiple times is not fun at all).

The name “soup of attributes” may not be a beautiful one, but believe me – it’s incredible. The idea is quite simple – instead of trying to handle all possible conversions from multiple sources to multiple destinations, you just define which attributes can be computed in terms of others, and Pathom does the rest. As always, things are better with examples, so let’s go.

I had to work on a system that somehow had strange rules – it needed to generate a bunch of text files for different companies. Each company expected a different file name and different fields. To generate the file, we had to accumulate data that came from a payload, from an external system that we called via REST API, and also from some data we had on our database. To make things worse, some companies would expect some of the data that was returned from REST on the filename, and there were also some state changes – like, if a file was already processed, the company would send us a return file, and we had to read some content of this file, move this file to another directory, renaming the file in the process.
(more…)

By Maurício Szabo, ago

Your editor as a query

Some time ago I found out this post: https://petevilter.me/post/datalog-typechecking/. It stroked me as really interesting – because it was an idea to make some IDE not depend on some internal API that only works for a single editor, but somehow make a tooling that’s query able by datalog. This datalog Read more…

By Maurício Szabo, ago

The power of finding facts about personal preferences

It is unfortunate, really, that it’s 2021, and we still try to justify our personal preferences with “facts” that simply don’t exist.

I’m really sorry if this sounds aggressive, but as someone that saw this same pattern happening again and again, I’m quite tired. As Obie told us on a great talk about programming, music students, and painting, the pallette is not the point! Programming languages, frameworks, libraries, virtual machines are pallettes, tools, to make things better. As as with anything, people will prefer water paint, or crayons, or whatever – it simply does not matter. What matters is the ability to make great tools. Imagine if we treated music the same way we do with programming languages. It’s not hard to imagine bizarre conversations like:

  • “What, you play piano? Why, how are you going to play on the streets? The streets is where you earn money, don’t you know?”
  • “Wait, why are you learning guitar? How are you going to play on an orchestra?”
  • “Ocean Drums? Why invent another percursion instrument?”

Sounds crazy, right? So, just read this tweet, and see the madness appearing. Maybe the way that Robert Martin posed the question was not the best way to convince people to try Clojure, but anyway, people jumped up on defense of their pallets, their tools, to the point it was quite tiring, really. I’ll not post who told what, and I’m not going to post the exact replies, but let’s debunk some myths:
(more…)

By Maurício Szabo, ago

Static Typing – the dangers of incomplete info

Ok, so I’m going to use this post – Making Illegal States Unrepresentable – and I’ll add my experience to it. For people that don’t know F# (or that don’t want to check all the post to see what’s the point), the idea is that he’s trying to construct a type that will only be valid if a user does at least an e-mail address or a postal contact. Then, he ends with the following type (I’m “inventing” a way to represent this type that’s close to Scala, but easier to read for people that don’t know Scala or Haskell or F#):

type Contact {
  Name: String
  AND Contact: ContactInfo
}

type ContactInfo {
  EmailOnly: EmailInfo
  OR PostOnly: PostalInfo
  OR EmailAndPost: EmailInfo with PostalInfo
}

// Types EmailInfo and PostalInfo have to be defined also

Then, he uses 13 lines to construct a ContactInfo, and another 12 to update a contact info. He ends up concluding that these complicated types are necessary because the logic is complicated. And that’s where we start to disagree.
(more…)

By Maurício Szabo, ago