Skip to content

Instantly share code, notes, and snippets.

@tclementdev
tclementdev / libdispatch-efficiency-tips.md
Last active November 15, 2024 01:56
Making efficient use of the libdispatch (GCD)

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

@dmonagle
dmonagle / ember_crud.coffee
Last active December 12, 2015 12:39
Ember mixins for CRUD functionality.
Ember.EditController = Ember.Mixin.create(
saveError: false
saveInvalid: false
isEditing: false
# Set associations to be associations of the content. These will then be checked for validity on save
# and all of the flags, such as isDirty and isLoaded, will take these associations into consideration.
#
# Eg: A user may have an address model which is edited within the same transaction.
# In this case you would put:
@tomdale
tomdale / gist:4263171
Created December 11, 2012 23:05
Ember Data Read-Only API Proposal

Read-Only

An important feature for Ember Data is providing helpful error messages when your application tries to do something that is forbidden by the data model.

To that end, we would like for the data model to be able to mark certain records, attributes, and relationships as read-only. This ensures that we can provide errors immediately, and not have to wait for a return trip from the adapter.

This also means that the adapter does not need to handle the case where an application developer inadvertently makes changes to a record that it does not conceptually make sense to modify on the client.

Requirements