remve perf.data, added comments

Author: tonibohnlein

include/osp/bsp/model/IBspSchedule.hpp

@@ -97,6 +97,10 @@ class IBspSchedule {
     /**
      * @brief Get the staleness of the schedule.
      *
+     * The staleness determines the minimum number of supersteps that must elapse between the
+     * assignment of a node to a processor and the assignment of one of its dependent neighbors
+     * to a different processor. For a standard BSP schedule, the staleness is 1.
+     *
      * @return The staleness of the schedule.
      */
     virtual unsigned GetStaleness() const { return 1; }

include/osp/bsp/scheduler/LocalSearch/KernighanLin/comm_cost_modules/FastDeltaTacker.hpp

@@ -20,6 +20,17 @@ limitations under the License.
 
 #include <vector>
 
+/**
+ * @brief Efficient sparse tracker for accumulating delta values across processors.
+ *
+ * FastDeltaTracker is used in local search algorithms (like Kernighan-Lin) to efficiently
+ * track incremental changes (deltas) to metrics such as communication costs for each processor.
+ * Instead of iterating over all processors to find or reset changes, it maintains a dense array
+ * for O(1) lookups and updates, alongside a sparse list (`dirtyProcs_`) of only the modified
+ * (non-zero) processors. This allows for fast O(1) additions, removals, and O(|dirty_procs|) clearing.
+ *
+ * @tparam CommWeightT The numerical type used for the communication weights/deltas.
+ */
 template <typename CommWeightT>
 struct FastDeltaTracker {
     std::vector<CommWeightT> denseVals_;      // Size: num_procs

include/osp/bsp/scheduler/LocalSearch/KernighanLin/kl_improver_scan.hpp

@@ -23,6 +23,21 @@ limitations under the License.
 
 namespace osp {
 
+/**
+ * @class KlImproverScan
+ * @brief An exhaustive, scan-based approach for finding the best Kernighan-Lin (KL) moves.
+ *
+ * This class implements a move-finding strategy that recomputes the gain for all active nodes
+ * after each move. Unlike priority queue based approaches that try to incrementally update
+ * affected nodes, `KlImproverScan` exhaustively scans the entire active set (`affinityTable_`)
+ * during each move selection phase to find the move(s) with the highest gain.
+ *
+ * This approach makes sense and is often preferred for more complex communication cost
+ * functions like BSP and Max BSP. In these models, a single move can trigger cascading cost
+ * updates for a very large number of nodes (compared to simpler models like total communication
+ * cost), making incremental priority queue updates highly inefficient due to the sheer volume
+ * of affected elements.
+ */
 template <typename GraphT,
           typename CommCostFunctionT,
           typename MemoryConstraintT = NoLocalSearchMemoryConstraint,