Tag Archives: performance

Notes on CSSConf Australia 2016

I attended CSSConf Australia in Melbourne on the 30th of November. A couple days ago, I wrote some generic notes about my experience in this conference and JSConf. This post covers specifically my notes for CSSConf.

The videos for the talks have not been published individually, but the conference was streamed live via YouTube, so you can watch the archived stream (you will have to “jump” to each talk):

And now, to my notes!
Continue reading Notes on CSSConf Australia 2016

Reading list, 4

~~~~shameless plug~shameless plug~shameless plug~shameless plug~shameless plug~~~~

Cover of Butterflies EP First of all — a SHAMELESS PLUG! I released my Butterflies EP last week and if you’re into electronic music you might want to check it out! There’s also a Too Long; Didn’t Listen (TL;DL) 1:30 version in SoundCloud, just in case you’re too busy for a full album 😀


Now for the non-shameless-pluggy list of links!

6th-12th April

  • Atomic Design by Brad Frost – This is a book on progress on an intriguing solution to a most relevant problem: designing for the immense variety of devices we use to access the net. I haven’t had much time to look into it, but it won me with just the first chapter’s tagline: “Create design systems, not pages”. I’m looking forward to Brad’s talk in UpFrontConf Manchester!
  • And also from Brad: Accessibility and low powered devices, and as he describes it: “an interesting intersection between performance, accessibility, and devices”.
  • Mozilla’s Web API Exposure guidelines – Mozilla is not using prefixes on new APIs anymore and opting for browser flags instead. This not news, but more of a reminder.
  • It’s OK for your open source library to be a bit shitty by David R. MacIver — “It’s not a job after all, is it? We’re not paying you to do it.” – except for when it seems to be, and it’s so damn exhausting sometimes. But as David says: “If the world comes back to you and says “You are a bad person for not supporting this thing I need you to support” then fuck them. If they want that they should pay you for it, or do it themselves.”
  • Surprise! Feminism – a follow up by David R. MacIver too! Or: why you will see way less women in Open Source, as it takes free time and money, two things we on average have less of.
  • What Your Open Source Culture Really Says, Part One by Shanley Kane – there are so many thought provoking points in the article, but “The only thing holding this project remotely together is romanticized notions of free and open source software” is a good one to start challenging yourself with. Can projects survive on a romantic idea? (answer: most definitely not)
  • The Spanish entity in charge of issuing SSL certificates for most of the country’s administrative and governmental servers uses certificates that trigger “this certificate is invalid” warnings in browsers. Thanks to bureaucracy, the bug is dragging for 7 years already. Fascinating and sad read, including typos in manually copied hashes, processes getting stuck for months because people go on holidays, and technical misconfigurations.
  • Making Music. Creative strategies for Electronic music producers by Dennis DeSantis who apparently wrote the Ableton live manual? – I have never been able to figure out how Ableton works; there’s something in its UI that doesn’t quite click with my brain, but the book looks interesting (and also beautiful). There are some chapters online!
  • And finally, a FUN ONE: Golden Girls LEGO set! I am a TENTE person but… this is really fun!

jQuery UK 2015

I attended jQuery UK past week, sorry about the delay in writing about it 🙂

The organisation was as smooth as it could be. They made sure we knew where, how and when to go to places and treated us really well, so it was a pleasure to be a speaker in this conference.

I must admit I was stupidly silly with regards to the conference at the very beginning. My programming bias elitism was yelling on my brain “oh I MIGHT NOT NEED jQUERY! Who needs it these days anyway!?”

But turns out that

  1. there’s lots of people who cannot afford to compromise on customer support, so they have to go the pragmatic way, and
  2. there’s a lot about newest web technologies we can share with them too!

So when they asked me to talk about Web Components I opted to frame it in the most pragmatic way too: how to use them without shooting yourself in the foot, so you can start working in a more modular way and taking in all those advantages.

I asked before starting and from an audience of… 300? 400 people? approximately 20 had heard about Web Components and about 10? had implemented them in a project. So I ran a quick introduction on what they were, why they were developed and how they looked like, before tackling them interoperating with the four main “frameworks”: jQuery, React, Ember and Angular.

A write up on the results of my research is upcoming, but in the meantime you can look at the slides if you’re so inclined. Be aware that something in Nightly was crashing with the slides at the time I presented, so if your browser crashes (including Nightly for Android)… you know why 😉

The talks I watched:

Addy Osmani gave an excellent talk on the state of Chrome’s developer tools and then explained how their team identified performance issues on Wikipedia, and how to fix them (this was related to Paul Irish advising people to not to use jQuery’s hide() method). Also, Paul is sorry for tweeting that without the proper context.

Natasha Rooney explained what Service Workers were and what problems they were meant to solve, but I am afraid if you had not a bit of background it would be a little bit confusing as the topic is *complex*.

Andy Hume explained various techniques on how to deliver fast experiences specially on mobile.

Alex Sexton infused us with a bit of South-West American culture and told us about don’t mess with Texas, then tried to find an equivalent for the web (don’t mess for the web?) with regards to hacking/building websites that cannot be hacked.

Jenn Schiffer explained all about vart.institute* and how it came to be. Also provided multiple screenshots of Dave Methvin keynoting at various jQuery events, which was quite amusing. And invited us to feel more empathy for people in the industry, which is a good thing if you ask me. *you can read it as fart and feel silly and it would also be totally OK

Estelle Weyl gave a very interesting talk on how to use forms and take advantage of all the cool features that browsers are already providing us but some people opt to rewrite in clumsy ways that go against all accessibility and usability best practices.

Ben Foxall did one of his shows (at this point we should call those a performance rather than giving a talk) where he involved everyone on the audience and elevated our phones from mere “phones” to interactive objects or “things” that transcend the simplest notion of “phone”.

I’m sorry I couldn’t watch the rest of talks, but it was great to meet Alice Bartlett, Rosie Campbell, Anne-Gaelle Colom, Rich Harris, Philip Roberts, David Rousset, and of course, Bodil Stokke!

After the last talk finished, we moved to the larger ‘hall’ style space where there were some snacks and drinks and people could mingle and ask questions if they hadn’t had the chance yet, so that was way better for me than going to a crammed pub, as I could walk between groups and speak to different people and not YELL ALL THE TIME. There were also some stands and also RETRO GAMES but I started talking to people and forgot to check out the games. AAAAH! Funny moment: Mike MacCana getting super excited about how he could help them setup multiplayer in DOOM using IPX.

All in all a very interesting conference for people who build websites and are willing to improve their practices or tooling… or both! I definitely learnt a bunch of things, so highly recommend checking it out next year!

ScotlandJS 2014 – day 2

(With a bit of delay, because socialising happened)

I am typing this at Brew Lab, having my last flat white at Edinburgh (total count in two weeks = about 7, I think). They aren’t paying me for this free advertising, but I want to say that it’s a cool hipster place literally and metaphorically up my street, coffee is quite good, and not only the wi-fi is free and works, but they also have power sockets. So there you go.

Keynote by Mikeal Rogers

Yesterday we barely made it in time for Mikeal Rogers’ keynote, and am certainly glad we rushed! I didn’t take many notes because I was mesmerised by his lighthearted telling of the evolution of his own code and how the improvements in node.js have brought better overall benefits not only for node.js, but also for the modules that have evolved alongside.

The whole talk is interesting to watch, but two things that stood out for me were why the node.js module ecosystem was so rich and growing:

  1. simplicity of interface:
    module.exports = function() { /* ... */ }

    –he explicitly insisted in returning a function call and not a simple object

  2. simplicity of callbacks signature:
    function(err, res) { /* ... */ }

I am pretty sure there was a third thing but he changed to some other topic or I got distracted, and forgot about it. So maybe it wasn’t that important!

“Refactoring legacy code” by Sugendran Ganess

What stood out for me: you want to have as many tests as possible and aspire to the maximum code coverage as possible. So when/if you refactor and you inadvertently change the existing behaviour of the system you notice before it’s too late.

Also: you want to be in master as soon as possible.

Finally he pointed to a couple of tools I want to check out: istanbul.js, platojs.

“Beyond the AST – A Fr**ework for Learnable Programming” by Jason Frame

This was totally unlike what I was actually expecting. The AST part tricked me into believing we were going to listen to some tree building and languages and grammar, but it was actually an enjoyable examination of how we generally teach programming and where we are doing it wrong. He said that natural language is taught in an incremental manner, and once you have a base you can start “getting creative”. In contrast, programming is often taught by throwing a list of concepts and constructs on the faces of people, and we expect them to get creative instantly. Which doesn’t quite work.

He also showed a prototype (?) environment he’d built that would fade out blocks of code that weren’t in the current scope (according to where the cursor was), so new programmers could notice or get a feel that those things weren’t accessible. That would allow him to “remove most sources of frustrations” for beginners.

This environment was also able to execute the program at a slower pace so you could see how the drawings would happen on the screen one at the time, instead of all in just one go. This reminded me to me learning programming with Logo and having to wait for the fill operation to complete because it would raster each line horizontally, from left to right, pixel by pixel. And it wasn’t fast 😛 (Incidentally, I discussed whether slow computers might be better for learning a couple years ago).

Some interesting lessons here, since us in my team are focused in getting more people to build apps, and so we spend lots of time analysing the current offering of materials and tools and trying to identify where the pain points are i.e. where the frustrations occur.

“High Performance Visualizations with Canvas” by Ryan Sandor Richards

This was a nice talk that described what the title says quite succinctly and to the point. He showed how to build graphs using static and realtime data, and something important – how to nicely transition between existing and incoming data, even when various latencies would occur (“networks are going to be networks”). Some of the interesting suggestions that not everyone might know about were, for example:

  • do not redraw static content in each frame. Just draw it once at the beginning and keep it on top with a higher z-index. In his example he would overlay an SVG object (with static content) with a Canvas object underneath (which would hold the changing chart)
  • Image copying is super fast. So if you already drawn part of the content, and can reuse it in the next frame, do it! Copy pixels!

However, I think he “cheated”. All the graphs and examples he showed were based in squares and new data would just come from the right and slide left, so bringing on new data was just a matter of copying the old canvas into the “display” canvas, only one unit to the left, and drawing the new one. When you don’t have much overlapping, it’s “easy” to increase performance “dramatically”. I was maybe expecting how to get crazy performance with complex visualisations where you can’t use this trick, but he didn’t cover that. Instead, he recognised that complex d3 visualisations would turn your computer “into a nuclear reactor”. A problem to solve, or a WebGL+GLSL job?

He also released a library for doing all these things: Epoch.

“Cylon.js: The JavaScript Evolution Of Open Source Robotics” by Ron Evans and his friend whose name I didn’t make a note of

This was a really entertaining, amusing and awesome talk! Ron was a very eloquent speaker who gave plenty of brilliant quotes for me to tweet, and then they also did lots of demos to SHOW not tell that their JS framework would allow you to write the same JS code once and run it in a myriad of physical devices. Arduino, Texel, some sort of round robots that would move by themselves, Pebble, and even drones and that sort of controller for “reading brain waves”. Sorry about not making a note of all of them–I was so amused by the display that I totally forgot.

This talk left me excited about building something with robots, which I guess it’s a measure of success. Good job!

“Make: the forgotten build tool” by James Coglan

An excellent introduction to make that actually answered the questions I wish someone had answered for me about 10 years ago. It really tempts me to go back to make, only I know that Windows users always have all the issues with it and so we have to write the build system in node so it’s something they can execute without having to install an additional tool (cygwin or whatever). Ah, I’m torn, because I really like make + bash…

“The Realtime Web: We’re Doing it Wrong” by Jonathan Martin

So–Jonathan was a good speaker, and the slides were fascinating to watch because they had plenty of animations that at that point of the day seemed really cool to look at. However, after the talk I still don’t know what are we actually doing wrong. I was expecting some sort of utterly mind-blowing revelation but it never happened.


With Mikeal Rogers, Angelina Fabbro and Mike MacCana, at a place with lots of pork meat and lots of drawings and watercolours of happy pigs in the walls. There’s absolutely nothing to complain about this.


“No more `grunt watch`: Modern build workflows with Broccoli” by Jo Liss

Revelation time: for the longest time, I thought Broccoli was a joke-response to the myriad of task runners such as Grunt, Gulp, and etc. So imagine when I learned that it was for reals!

Jo went straight to the point and showed why Broccoli was better than Grunt in specific domains, and demonstrated how to use Broccoli to build a project. The syntax seemed way more imperative than Grunt’s–and way easier to understand. The core concept in Broccoli is trees of files, which, I confirmed with her afterwards, is why Broccoli is called Broccoli. I mean, just look at one and see how it branches into smaller broccolis!

“Build Your Own AngularJS” by Tero Parviainen

Being honest: Tero didn’t catch my attention during the first minutes so I zoned out and kept thinking about how to improve canvas performance. Related: this article about graphics performance in Firefox OS/mobile devices.

“Don’t Go Changin'” by Matt Field

This was a disappointment to me: I thought he’d show a magic clever hack to work with immutable objects in JavaScript but instead he started describing how he’d do things with Clojure where those things are actually native. I tried to stay but my brain wasn’t patient enough for a short introduction on Clojure on the spot, so I left. But…

Impromptu conversation in the hallway!

… I happened to find Jo Liss and some other guy (whose name I didn’t catch, sorry) in the hallway. And somehow we engaged on a conversation about how to onboard new contributors to your project, or even how to get someone to contribute at all. A suggestion was to encourage newcomers to start fixing things in the documentation—a simple “task” that shouldn’t break the code. I described how some teams do it in Mozilla: there’s the Bugs Ahoy! website which keeps tracks of bugs marked as “good first bug” and bugs with assigned mentors. Also, at a past work week in my team we had a similar conversation where we agreed that having an explicit and visible list of issues/to do items made it easy for people to actually get their hands dirty.

Also: how do you steer the project in a direction that makes sense without frustrating contributors and/or maintainers, and without falling in the Feature Creep pit either? One suggestion was to make it very clear what the project was about. Don’t try to solve all the issues, but rather do something, and do it well.

And empower your contributors. Once someone steps in and submits something valuable, treat them as equal peers. Give them commit access. People don’t rush to make stupid things when they get superpowers (unless they’re villains). Instead, they feel honoured and try to make the best they can. Or in other words: if you trust people, you’ll get way better outcomes than if you think they’re all silly and irresponsible.

At this point we actually left the conference before it finished because… *~~~ BRAIN FRIED ~~~*

So sorry but I can’t comment on the rest of the talks.

However, I can tell you that I realised that yesterday was the Eurovision finale, and since Angelina had never seen one, we had a fun time watching it, with me explaining all the politics in play. We really appreciated the impromptu booing, felt the pain of the pretty Finland guys losing to the Netherlands and wholeheartedly agreed that

  1. the stage was one of the best parts of the show, and
  2. any act with keytars should get an extra bunch of points.


This was a good conference with WORKING WI-FI, lots of different topics—although not all of them catered to me, which I guess is OK, and good atmosphere overall.

However at times it felt a bit weird that there weren’t even 10 non-males at the room (that’s a guesstimation based on external looks, and includes the three non-male speakers out of a total 26 talks). The speakers were also quite homogeneously white males so mmm. Often I went to the ladies toilette and the automatic light sensor would turn on the lights, because there were so few of us that it had turned off after a long period of no one entering. That’s unnerving. Is it the Scotland JS community that skewed? I see wider diversity in London events, and I want to see wider diversity in other events too.

I also want to thank Pete Aitken and the rest of the team for organising this conference and being as accommodating, efficient and helpful as they were every time we asked them for anything. Thanks!

You can also read ScotlandJS 2014, day 1.

Performance research

After I managed to get the Android emulator to make some noise, I decided it was a good time to experiment and research what was the best way to get better sound performance with Android.

On my last post I had expressed some doubts about my own code: was I optimizing too early? So I tried several things to prove myself wrong (or right). It turned out I was right in trying to optimize from the beginning:

  1. First I changed all the calls to my humble sin Look Up Table (LUT) with calls to the real, meaty Math.sin function. It works with the double data type — so that means that it would require a decent Floating Point Unit (FPU) for delivering all the data in time. Consequently, it all ended with stuttered sound, and recurrent gaps in the generated wave, because the thread couldn’t fill the audio buffer in time.
  2. Then I tried using Toxi’s Trigonometric LUT functions and fast sin function, if only to compare them with my rudimentary LUT techniques. Unfortunately, although they did well with my first and only 64k intro, they still use float, so I was still getting gaps in the audio.

So it seemed that my approach was heading towards the right direction. What I mean with my approach is that when I precompute the values of the LU tables, I am calculating shorts already. Why? Because the final output (i.e. the audio buffer) uses shorts as well. It is quite a change for me, because in my previous attempts at sound synthesis I was using floats internally all the way, and only converted to integers in the last phase, when filling in the buffer that would be returned to the callback function.

Changing from floats to integers/shorts means I have to change the usual mental scale as well. You can’t think in terms of the oscillator values being in a [-1, 1] range, but in the [-32767, 32767] instead — only without intermediate (fractional) values. That effectively reduces precision, but I think it’s fine to compromise a bit on the audio quality in this case: it’s not like your phone is connected to high end speakers.

Just to clarify: I am not using fixed point math, and I am unsure whether that’s a good idea. For starters, I have never written any fixed point routine, let alone use it (that I am aware of). It seems there are libraries which you can use, but it seems their performance is not exactly stellar with devices such as this phone.

So what I am doing is using integers and shorts as much as possible, with the occasional use of a float here and there. I am also trying to simplify the work done inside loops, so for example I extract some multiplications and try to convert things to sums only. Hopefully this approach will allow me to have some extra precious spare CPU cycles for graphics in the application 😛

And what do Android developers say?

There’s a veeery long thread discussing these points at the android developers group. This is what a couple of Android developers say:

Don’t count on floating point hardware being the common case. The mobile space is very different than what you may be used to in the desktop world, in that there are two factors that drive mobile device design just as much as performance does in the desktop world: battery life and cost. Including floating point hardware support has a negative impact on both of these, so if the performance gain isn’t going to strongly help sell the phone then there is very little incentive to have it.

Another good thing to be aware of about the mobile space is the range of hardware is much broader than desktops. That is, the difference in performance between a low-end and high-end mobile device is much larger than corresponding difference in desktop systems. In addition, most of the phones in use are down in the low-end spectrum, so if you want to have any broad use of your software then you need to think about how it will work on those low-end devices.

(by Dianne Hackborn)

and this one at the end:

A single interpreted dalvik instruction, be it a “NOP”, costs about the same than a softfp multiply.
A float-to-int or int-to-float operation costs about 15 CPU cycles.
At the lowest level, a softfp add or mul costs about 20 CPU cycles.
At the lowest level, a integer add costs 1 CPU cycle, while a multiply costs between 2 and 6 cycles.
An integer divide can cost up to 100+ CPU cycles, be it integer or softfp
Most ARM CPUs don’t even have an integer divide instruction (it’s done by hand, just like in elementary school, but in binary! :)).

So, to conclude:

– avoid divides/modulos at all cost float or integer

– floating point operations in interpreted java language/dalvik are only roughly half the speed of the equivalent integer operation, so it’s not /that/ slow.

– try to avoid using floats too much, but don’t sweat it, simply try to take as much computation as possible out of tight loops.

– use integer whenever it makes sense and as much as *possible*

– in the case of a JITted VM or native code, avoid floats like the plague, since they are an order of magnitude slower than their integer counterparts.

by Mathias Agopian.

So it looks like I am on the right track. Winden also confirmed that the best thing is to avoid floats in ARM-powered devices (by email) and I believe if so many people point to this path, it must be the right one, mustn’t it? 😀

With a bit of luck, the next post should be about my first impressions about OpenGL ES in Android.