As a brief note today, if you need to read a binary file with Scala, here’s an approach I just tested and used. It uses the Java FileInputStream and BufferedInputStream classes:
Today I learned that for several reasons, Flutter Debug mode may be significantly slower than Production mode. As just one reason, Debug mode is compiled using JIT while Production mode uses AOT. You can read more about the reasons on the Flutter UI Performance page.
A very important note on that page is that if you’re using a real hardware device (as opposed to an emulator), you can run your code in Profile mode like this:
At the time of this writing (September 19, 2019), there’s a lot of bad information in books and on the internet about how to use a Flutter FutureBuilder. That bad information caused me to waste a lot of time over the last two days. I don’t have time today to explain everything, but in short, here’s a technically correct FutureBuilder example:
As a brief note today, I found that GraalVM was actually making one of my Scala/Java/JVM applications slower, so with the help of Thomas Wuerthinger at Oracle, I learned a little bit about how to use the GraalVM profile-guided optimizations.
I’m working on a small project to parse large Apache access log files, with the file this week weighing in at 9.2 GB and 33,444,922 lines. So I gave myself 90 minutes to try a few different ways to write a simple “line count” program in Scala. (Not my final goal, but something I could use to measure file-reading speed without applying my algorithm.)
When I saw this tweet this morning:
[DOG MAGICIAN] think of a color, any color ... is it ... gray?
[OTHER DOG] oh my GOD
I knew that I loved the joke, but I didn’t like the presentation. I wanted to put the joke on Facebook, but I know that people like images more than they like text, so I made a second cup of coffee and began putting the text on an image.
In two small tests where GraalVM was able to create a native executable, the native executable ran significantly faster than the equivalent Scala/Java code running with the Java 8 JVM, and also reduced RAM consumption by a whopping 98% in a long-running example. On the negative side, GraalVM currently doesn’t seem to work with Swing applications.
I used to use wunderground.com all the time. Then, over time, I noticed that it kept getting slower and slower. Out of frustration I looked around for other good weather websites. Today I use accuweather.com.
On the web and with apps, performance — or lack of performance — is important to acquiring and retaining customers.
This article on When to use Web Workers had this good chart that shows that smartphone CPUs aren’t hitting a performance wall in the same way that PC CPUs did in 2005.
I had read that Bloop was faster than Scala compiler tools like scalac and fsc, so I wondered if it was faster than SBT, and if so, how much faster. So I downloaded Eric Torreborre’s specs2 source code, which has 880 source code files, and compiled the entire project with both SBT and Bloop.
To test SBT’s speed, I ran all the commands from inside the SBT command prompt, which I usually do anyway to avoid the SBT/JVM startup lag time. I also ran clean and compile several times before recording SBT’s speed, because I thought that would be a better reflection of real-world usage and performance. I ran the tests four times, and the average time with SBT was 49 seconds, and that was very consistent, always coming in between 48 and 50 seconds.
