cross-reference the two profiling ideas

README.md

@@ -198,6 +198,10 @@ like netsend, netreceive, etc.)
   by just hand-unrolling one or two classes when N=64 (i.e., the most common
   block size) and measuring the performance impact (if any).
 
+Note: There may be some overlap with the other profiling idea listed below.
+Developers for both ideas may therefore benefit by periodically sharing their
+work with each other.
+
 Difficulty: Moderate to hard. The initial profiling will take some time but
 isn't particularly challenging. Making changes to the core audio engine,
 however, will require some knowledge of Linux system interfaces and some of
@@ -348,6 +352,10 @@ same time. Thus, a robust keyboard navigation implementation will help
 make it possible for screen readers to give meaningful information about
 each node in the graph.
 
+Note: there may be some overlap with the REPL idea above, as the REPL could
+provide a sensible way for a user to traverse the diagram as an alternative
+to using the GUI.
+
 Difficulty: Moderate. For example, it will be necessary to study the current
 GUI implementation to figure out how to extend it to add keyboard navigation.
 It will also be necessary to study pre-existing approaches to making SVG
@@ -386,6 +394,10 @@ reliable on modern machines, the overall approach taken by DesireData of
 adding a field to the t_gobj struct for storing this timing data is
 probably a sound starting point.
 
+Note: There may be overlap with the other profiling idea listed above, as
+developers on both ideas will probably be using the same tools and can
+therefore benefit by periodically sharing their work with each other.
+
 Bonus goal: Figure out a way to meaningfully profile DSP objects. DSP objects
 typically process data at a high sample rate (44,100 is common) so displaying
 the data in a user-friendly and meaningful way is tricky.