Monday, May 12, 2014

Code for Javascript Web Workers in same file as main script

Javascript's Web Workers (actually HTML 5's) have a lot of potential and they're surprisingly safe to use. They're safe because we sacrifice one of the main benefits of threading: sharing memory. Values between the main thread and worker threads are copied, not pointed to, so you have that overhead to deal with. (You send messages between threads rather than sharing memory.)

Anyway, in JS libraries especially, it can be useful to spawn worker threads, but it's inconvenient to have those functions in entirely separate files sometimes. I'm not 100% sure of the implications yet, but I had some success with the following template:

/*
Template for worker script in same file as main script;
adapted from http://stackoverflow.com/a/10136565/1048862
to make it a little cleaner
*/
(function(global)
{
  "use strict";

  var isWorker = !global.document;

if (isWorker)
WorkerThread();
else
MainThread();



// Entry point for when we're a worker thread
function WorkerThread()
{
global.onmessage = messageReceived;


// Worker thread execution goes here...
// This is how to pass messages back to the main/parent script
// global.postMessage("From worker!");
// (messages can also be objects)

function messageReceived(e)
{
console.log("Worker received message from parent:");
console.log(e.data);
}
}



// Entry point for the main thread
function MainThread()
{
var SCRIPT_PATH = getScriptPath();

// Main script execution goes here...
// This is how to start new workers and pass messages:
// var w = newWorker();
// w.postMessage("From parent!");


function getScriptPath()
{
var id = "worker" + String(Math.random()).substr(2);
document.write('<script id="'+id+'"></script>');
return document.getElementById(id).previousSibling.src;
}

function newWorker()
{
var w = new global.Worker(SCRIPT_PATH);
w.onmessage = messageReceived;
return w;
}

function messageReceived(e)
{
console.log("Parent received message from worker: ", e.data);
}
}

})(this);

Anyway, I think I might use this again.

Monday, May 5, 2014

Scribbles from GopherCon 2014

Just a few notes I jotted down when I wasn't too mesmerized by the presentations... they probably won't make sense unless you were there or can see the talks. I'm mostly posting these for my own benefit. Anyway...

High Performance Go

  • Use go tool pprof (linux)
  • Avoid short-lived objects on the heap
  • Use the stack or make long-lived objects
  • Benchmark standard library builtins (strconv)
  • Benchmark builtins (defer, hashmap)
  • Don't use channels in performance-critical paths

CSP (Communicating sequential processes)

Unbuffered channels are nice because there's no ambiguity: you know that both sides are communicating right now, and are synchronizing.

Nil channels block; they can be used in selects to know when multiple channels are closed

Bluetooth Low Energy (BLE) and Embedded Go

If you're worried about GC pauses, think about the number of allocs as much as the size of your allocs.

Sysadmins

You don't need to have a big problem to solve to use Go.

Heka (on streaming data)

Basic pattern: read in data from a stream, split at record boundaries, transcode the records to a common format, route to the appropriate service in its own format.

Bind a single struct to a goroutine (or a single goroutine to a struct).

High-performance database in Go

(From basic OS classes) How to think about performance: optimize the following from least optimization efforts to most: Memory access, mutual exclusion, memory allocation, disk I/O, network I/O

MongoDB and Go

Rethink using Rethink.

But maybe rethink using Mongo, too. Choose the right tool for the job.

database/sql

The DB type represents your database; it is not a connection.