Use CustomLayout instead of SubcomposeLayout

[kosenda]

Summary

This PR replaces SubcomposeLayout with Layout API to improve performance and simplify the code structure.

Changes

• Replaced SubcomposeLayout with Layout API in AutoSizeTable.kt
• Introduced state management using remember and mutableStateOf to cache measured table item sizes
• Refactored the measurement logic to measure all items first, then compose the content with the calculated sizes
• Reduced redundant recompositions by caching the TableItemSize state

Benefits

• Improved Performance: The Layout API is more efficient than SubcomposeLayout for this use case, as it avoids the overhead of dynamic subcomposition
• Better State Management: Table item sizes are now properly cached and only updated when measurements change
• Cleaner Code: The measurement and layout logic is more straightforward and easier to maintain

Related Issue

Closes #49

Testing

• Existing functionality verified with sample app
• Table rendering works correctly with fixed rows/columns
• Dynamic content updates properly reflected

[Copilot]

Pull Request Overview

This PR refactors the MeasureTable composable to replace SubcomposeLayout with a standard Layout combined with state management. This change aims to address performance issues mentioned in the README by using a more efficient measurement approach.

Key Changes:

• Replaced SubcomposeLayout with Layout and state-based measurement tracking
• Introduced tableItemSize state to cache measured dimensions
• Changed from dynamic subcomposition to upfront composition of all items

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Mutating state during layout measurement phase can cause infinite recomposition loops. State updates in the measure lambda trigger recomposition, which triggers measurement again. Consider using SideEffect or LaunchedEffect to update state, or restructure to avoid state mutation during layout.

[Copilot]

All table items are now composed and measured on every recomposition, even when they haven't changed. The previous SubcomposeLayout approach only composed items as needed. This could significantly worsen performance for large tables. Consider using keys in the composition or reverting to a subcomposition approach if performance is critical.

Suggested change

	Box {
	item()
	androidx.compose.runtime.key(rowIndex to columnIndex) {
	Box {
	item()
	}

[Copilot]

The rowIndex and columnIndex variables are declared but never used within the nested loops. Consider removing these parameters or using underscore (_) to indicate they are intentionally unused.

Suggested change

	items.forEachIndexed { rowIndex, rowList ->
	rowList.forEachIndexed { columnIndex, item ->
	items.forEachIndexed { _, rowList ->
	rowList.forEachIndexed { _, item ->

[Copilot]

Wrapping items in a Box without any modifiers or parameters adds an unnecessary layer of composition. Consider invoking item() directly unless the Box serves a specific purpose.

Suggested change

	Box {
	item()
	}
	item()

[Copilot]

Using .first() after .drop() will throw NoSuchElementException if the content lambda doesn't emit any measurables. This could happen if the content is conditional or empty. Consider using .firstOrNull() with null handling or add a check to ensure at least one content measurable exists.

Suggested change

	val contentPlaceable = measurables.drop(itemCount).first().measure(constraints)
	layout(contentPlaceable.width, contentPlaceable.height) {
	// Only place the content, not the measurement items
	contentPlaceable.place(0, 0)
	val contentMeasurable = measurables.drop(itemCount).firstOrNull()
	if (contentMeasurable != null) {
	val contentPlaceable = contentMeasurable.measure(constraints)
	layout(contentPlaceable.width, contentPlaceable.height) {
	// Only place the content, not the measurement items
	contentPlaceable.place(0, 0)
	}
	} else {
	// No content measurable, layout with zero size
	layout(0, 0) { }

[kosenda]

Performance Comparison: SubcomposeLayout vs Layout API

Overview

After further testing, it appears that SubcomposeLayout may perform better than Layout API when the number of cells is small. This requires a more thorough analysis before merging.

SubcomposeLayout Approach (Current main branch)

Advantages

1. Better for Small Tables: When the table has fewer cells (e.g., 3x3 to 5x5), SubcomposeLayout shows better performance

   • Lazy composition: Only composes items when they're actually needed for measurement
   • Native support for dynamic content composition

2. Simpler State Management:

   • No need to manually manage state with mutableStateOf
   • Measurement and composition happen in one pass
   • Automatically handles recomposition when content changes

3. Memory Efficient for Small Data:

   • Doesn't create all measurables upfront
   • Composes items on-demand during measurement phase

4. Less Code Complexity:

   • No need for separate state tracking
   • Built-in subcomposition lifecycle management

Disadvantages

1. Overhead for Large Tables:

   • SubcomposeLayout has additional overhead for managing subcomposition
   • May be slower when dealing with many cells (e.g., 20x20 or larger)

2. Multiple Composition Passes:

   • Items may be composed multiple times (once for measurement, once for display)
   • This can be expensive if cell content is complex

3. Less Control:

   • Cannot easily optimize the measurement strategy
   • Harder to implement custom caching strategies

Layout API Approach (This PR)

Advantages

1. Better for Large Tables:

   • Single measurement pass for all items
   • More predictable performance characteristics
   • Lower overhead per cell when there are many cells

2. Explicit State Caching:

   • Measured sizes are explicitly cached in state
   • Only updates when measurements actually change
   • Can prevent unnecessary recompositions

3. Full Control Over Lifecycle:

   • Complete control over when items are composed and measured
   • Can implement custom optimization strategies
   • Easier to add performance optimizations in the future

4. Modern API:

   • Layout is the recommended modern approach in Compose
   • Better aligned with Compose's current best practices

Disadvantages

1. Overhead for Small Tables:

   • Always composes all items upfront (even if not all are needed)
   • State management adds overhead when there are few cells
   • Extra composition for measurement items that are never placed

2. More Complex Code:

   • Requires manual state management with mutableStateOf
   • Need to handle state updates carefully
   • More code to maintain

3. Potential Infinite Recomposition:

   • If state updates are not handled correctly, can cause recomposition loops
   • Requires careful equality checks (currently mitigated with data class comparison)

4. Memory Overhead:

   • All items are composed twice: once for measurement, once for display
   • May use more memory for the measurable objects

Recommendations

When to Use SubcomposeLayout

• Small to medium-sized tables (< 10x10 cells)
• Tables with complex cell content that's expensive to compose
• When simplicity and maintainability are priorities
• When memory usage is a concern for small datasets

When to Use Layout API

• Large tables (> 10x10 cells)
• Tables that need custom layout optimizations
• When you need explicit control over composition lifecycle
• When using the most modern Compose APIs is important

Benchmark Needed

To make a definitive decision, we need to:

1. Create benchmarks for various table sizes (3x3, 5x5, 10x10, 20x20, 50x50)
2. Test with both simple (Text) and complex (Image + Text) cell content
3. Measure composition time, recomposition frequency, and memory usage
4. Test scroll performance for both approaches

Conclusion

The choice depends on the use case:

• For a general-purpose library like AutoSizeTable that may be used for both small and large tables, we need to either:
  1. Keep SubcomposeLayout for its simplicity and better small-table performance, OR
  2. Implement the Layout API with additional optimizations to match SubcomposeLayout's small-table performance, OR
  3. Provide both implementations and let users choose based on their needs

Current Recommendation: Convert this PR to draft and conduct thorough benchmarks before making a final decision. The simpler SubcomposeLayout approach may be preferable unless we can demonstrate clear benefits for the Layout API approach across all use cases.