Jiyee Sheng jiyee

libdispatch efficiency tips

The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).

My take-aways are:

You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.
Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse

USE AT OWN RISK

This was only tested on a 'partial' SentinelOne installation on the High Sierra beta, where SentinelOne was never allowed to enable it's kernel extension. (Some things failed while I was messing around with OS betas.)

This script is most likely outdated.

A lot happens in 2+ years, at this point there's a good chance this script will do more harm than good. Read the comments before using!

FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.

Effective Engineer - Notes

By Edmond Lau
Highly Recommended 👍
http://www.theeffectiveengineer.com/

What's an Effective Engineer?

Why I think Webpack is the right approach to build pipelines

(I've reposted this on my blog, which you may find more pleasant to read: http://devlog.disco.zone/2016/06/01/webpack/)

I was asked on Twitter why I think Webpack is the right approach to build tooling in JavaScript applications. My explanation is, uh, a bit longer than fit in a single tweet.

When I say "right approach," I'm specifically talking about the way Webpack's pipeline functions. There are certainly some deficiencies in various aspects of Webpack: it has a rather unintuitive API, and often requires quite a bit of boilerplate to set up. However, even with these issues, I think the core principles of how Webpack functions are sound.

I should also mention here this argument basically applies to SystemJS as well. I'm skeptical of various aspects of SystemJS, but I've only taken a very surface-level look at it, so I'm gonna withhold judgement until I've had a chance

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

	# This snippet shows how to enable dyld `closured` and how to fix `read` implementation in dyld using lldb.
	# Following text is a bash/lldb command mix and it contains the relevant stdout content and my comments.

	// `DYLD_PRINT_WARNINGS=1` environment variable will print dyld logs
	$ DYLD_PRINT_WARNINGS=1 lldb /Users/kamil.borzym/tmp/TestMacApp.app/Contents/MacOS/TestMacApp

	(lldb) process launch --stop-at-entry

	(lldb) image list
	[ 0] D355CCB5-8584-33E3-8DF7-7BA95BAD41AF 0x0000000100000000 /Users/kamil.borzym/tmp/TestMacApp.app/Contents/MacOS/TestMacApp

	#!/bin/bash
	# Dennis Ullrich
	# Version 0.1-0 (2017-06-29)
	# [email protected]

	# Bash Version 3 required (it also works with ksh)
	[[ ${BASH_VERSINFO[0]} -lt 3 ]] && exit 1

	# Defaults
	stdin=0

	//cc -Wextra -o build/dump-header-map dump-header-map.c
	// see: https://github.com/llvm-mirror/clang/blob/release_40/include/clang/Lex/HeaderMapTypes.h
	// https://github.com/llvm-mirror/clang/blob/release_40/include/clang/Lex/HeaderMap.h// https://github.com/llvm-mirror/clang/blob/release_40/lib/Lex/HeaderMap.cpp

	// This is basically dump() from there.

	#include <stdio.h>
	#include <stdlib.h>
	#include <sysexits.h>
	#include <err.h>

	The MIT License (MIT)

	Copyright (c) 2016 Zev Eisenberg

	Permission is hereby granted, free of charge, to any person obtaining a copy of
	this software and associated documentation files (the "Software"), to deal in
	the Software without restriction, including without limitation the rights to
	use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
	the Software, and to permit persons to whom the Software is furnished to do so,
	subject to the following conditions:

	{-# LANGUAGE OverloadedStrings #-}
	module DGPHParser(parseDgph) where

	import qualified Data.Attoparsec.ByteString as A
	import qualified Data.ByteString as B
	import Data.Bits
	import Data.Foldable (foldl')
	import qualified Data.ByteString as B
	import qualified Data.Attoparsec.ByteString as A