some notes on performance

contents/iteration.ipynb

@@ -964,25 +964,25 @@
  },
  {
  "cell_type": "code",
- "execution_count": 7,
+ "execution_count": 3,
  "metadata": {},
  "outputs": [],
  "source": [
  "]dinput\n",
  "bsearch ← {⎕IO←0\n",
- " 0 (⍺ { ⍝ Operator: ⍺,⍵ - lower,upper index. ⍺⍺ - item, ⍵⍵ - array\n",
- " ⍺>⍵:¯1 ⍝ If lower index has moved past upper, item's not present\n",
- " mid ← ⌈0.5×⍺+⍵ ⍝ New midpoint \n",
- " ⍺⍺=mid⊃⍵⍵:mid ⍝ Check if item is at the new midpoint\n",
- " ⍺⍺<mid⊃⍵⍵:⍺∇¯1+mid ⍝ Drill into lower half\n",
- " (1+mid)∇⍵ ⍝ Upper half\n",
+ " 0 (⍺ {  ⍝ Operator: ⍺,⍵ - lower,upper index. ⍺⍺ - item, ⍵⍵ - array\n",
+ " ⍺>⍵: ⍬  ⍝ If lower index has moved past upper, item's not present\n",
+ " mid ← ⌈0.5×⍺+⍵  ⍝ New midpoint \n",
+ " ⍺⍺=mid⊃⍵⍵: mid ⍝ Check if item is at the new midpoint\n",
+ " ⍺⍺<mid⊃⍵⍵: ⍺∇¯1+mid ⍝ Drill into lower half\n",
+ " ⍵∇⍨1+mid  ⍝ Upper half\n",
  " }(,⍵)) ¯1+≢,⍵\n",
  "}"
  ]
  },
  {
  "cell_type": "code",
- "execution_count": 3,
+ "execution_count": 4,
  "metadata": {},
  "outputs": [
  {
@@ -992,7 +992,7 @@
  "</span>"
  ]
  },
- "execution_count": 3,
+ "execution_count": 4,
  "metadata": {},
  "output_type": "execute_result"
  },
@@ -1003,7 +1003,7 @@
  "</span>"
  ]
  },
- "execution_count": 3,
+ "execution_count": 4,
  "metadata": {},
  "output_type": "execute_result"
  },
@@ -1014,7 +1014,7 @@
  "</span>"
  ]
  },
- "execution_count": 3,
+ "execution_count": 4,
  "metadata": {},
  "output_type": "execute_result"
  },
@@ -1025,18 +1025,20 @@
  "</span>"
  ]
  },
- "execution_count": 3,
+ "execution_count": 4,
  "metadata": {},
  "output_type": "execute_result"
  },
  {
  "data": {
  "text/html": [
- "<span style=\"white-space:pre; font-family: monospace\">¯1\n",
+ "<span style=\"white-space:pre; font-family: monospace\">┌⊖┐\n",
+ "│0│\n",
+ "└~┘\n",
  "</span>"
  ]
  },
- "execution_count": 3,
+ "execution_count": 4,
  "metadata": {},
  "output_type": "execute_result"
  }
@@ -1046,7 +1048,7 @@
  "5 bsearch 0 2 3 5 8 12\n",
  "5 bsearch 5 5\n",
  "5 bsearch 5\n",
- "1 bsearch 0 2 3 5 8 12"
+ "]display 1 bsearch 0 2 3 5 8 12"
  ]
  },
  {
@@ -1236,7 +1238,7 @@
  },
  {
  "cell_type": "code",
- "execution_count": 14,
+ "execution_count": 5,
  "metadata": {},
  "outputs": [],
  "source": [
@@ -1272,6 +1274,45 @@
  "Quite a staggering difference for such an innocuous change, perhaps."
  ]
  },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "The binary search implementation we concluded the previous section above with already 'does the right thing' -- it doesn't cut off the data array on each iteration. So it should be fast, right? Searching for a number amongst a million or so _must_ be faster than the APL primitive function that examines every element looking for a match. Surely...? In `Algorithms 101` they taught you that `O(log n)` always beats `O(n)`. Except when it doesn't:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 9,
+ "metadata": {},
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "<span style=\"white-space:pre; font-family: monospace\"> data ⍳ 17777 → 1.6E¯6 | 0% ⎕⎕⎕⎕ \n",
+ "* 17777 bsearch data → 1.5E¯5 | +842% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕\n",
+ "</span>"
+ ]
+ },
+ "execution_count": 9,
+ "metadata": {},
+ "output_type": "execute_result"
+ }
+ ],
+ "source": [
+ "data ← ⍳100000 ⍝ A meeeeelion numbers\n",
+ "cmpx 'data ⍳ 17777' '17777 bsearch data' ⍝ Look for the number 17777"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Ouch... a lesson for the APL neophyte here. Your intuition for what's efficient and what isn't is almost certainly wrong. Key point: simple APL primitives on simple arrays are always faster than anything you can write in APL. Only ever iterate if there are no other alternatives.\n",
+ "\n",
+ "Exercise for the reader: as the data grows, sooner or later the `bsearch` function will win out. How large does the array need to be for that to happen?"
+ ]
+ },
  {
  "cell_type": "markdown",
  "metadata": {},