speed

Five good ways (and two bad ways) to read large text files with Scala alvin July 28, 2019 - 5:58pm

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.)

Good design: Quantity leads to quality (and iteration speed is vital)

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.

GraalVM native executables can run faster than Scala/Java/JVM applications, with much less memory consumption

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.

Performance is important to acquiring and retaining customers.

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.

Bloop’s compiler performance is ~29% faster than SBT (on at least one project)

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.

SBT performance

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.

Bloop performance

Triplequote: A Guide to Amazon EC2 instance types alvin March 10, 2019 - 11:27am

The people at Triplequote looked at the performance of Scala compilers on different Amazon EC2 instance types in an effort to answer the question, “What is the (cloud) cost per build?”

Measuring Scrum team productivity/speed with Function Point Analysis

I bought my first copy of Agile Software Development with Scrum, by Schwarber and Beedle back around 2002, I think. I was just thumbing through it last night when I saw that they use Function Points as a metric to demonstrate the velocity that agile software teams achieve, and more specifically use it to show that some teams develop software much faster using Scrum.

I didn’t know about Function Point Analysis back in 2002 — I didn’t become a Certified Function Point Specialist until about two years later — so I probably just skimmed over that line then, but when I saw it last night I thought it was cool that they used function points as a metric for software team development speed.

Computer latency: 1977-2017 alvin February 10, 2019 - 6:24pm

A friend sent me this link about computer latency.