Kotlin Performance Optimization Silently Disables Features

Introduction: The Stealthy Saboteur of Features

Executive Summary & Key Takeaways

• Silent Feature Disabling Risk: Performance optimizations can inadvertently disable features without triggering errors, leading to unnoticed application behavior changes.
• Comprehensive Testing Required: Testing should not only focus on performance improvements but also re-verify all dependent features to prevent silent bugs.
• Impact of Optimization on Functionality: Optimizing for specific performance metrics can alter execution paths and data sets, affecting unrelated functionalities.
• Awareness of Kotlin-Specific Challenges: Kotlin's concurrent and reactive programming patterns can obscure side effects, increasing the risk of silent feature bugs.

In the relentless pursuit of speed and efficiency, developers often walk a fine line. Performance optimization is a critical aspect of delivering robust, scalable applications, especially in high-demand environments. Yet, the act of streamlining code, enhancing database queries, or refactoring for better throughput can sometimes have unforeseen consequences. We’re not talking about outright crashes or obvious errors that trigger immediate alerts. Instead, we refer to a far more dangerous phenomenon: silent feature disabling. This occurs when an optimization, seemingly successful in its primary goal, inadvertently alters the application's behavior in a way that goes unnoticed by standard functional tests, quietly stripping away functionality without a single error message. This post-mortem deep dive explores how such catastrophic bugs can manifest and, more importantly, how to prevent them.

The Silent Killer: How Optimization Turns Treacherous

The journey from a feature request to a deployed, optimized solution is often complex. When performance bottlenecks emerge, the natural inclination is to address them swiftly. This might involve optimizing CPU-bound computations, reducing network latency, or refining database interactions. While the intent is always to improve, the side effects can be devastating. A performance tweak, particularly one targeting a specific performance metric, can inadvertently alter data sets, timing, or execution paths that other, seemingly unrelated features depend on. The immediate performance gain often masks this deeper issue, leading to a false sense of success.

The problem is exacerbated when testing focuses solely on the performance aspect of the change or the directly impacted functional areas, neglecting to systematically re-verify all dependent features. This oversight creates a window for silent feature bugs to slip into production. Such bugs are notoriously hard to debug because they don't manifest as exceptions but rather as incorrect application states or missing options that users discover, often much later, when they attempt to use the "optimized away" functionality. The challenge lies in our inherent bias to validate what we changed, not necessarily what we might have unintentionally affected. This is a common pitfall in Kotlin performance optimization dangers, where highly concurrent and reactive patterns can further obscure side effects.

Many applications, especially those built with Kotlin, are heavily dependent on efficient database interactions. It's common for performance bottlenecks to be database bounding. Developers often focus on optimizing SQL queries – adding indexes, restructuring joins, or refining WHERE clauses – to reduce execution time and resource consumption. While these are valid and necessary steps for SQL query optimization, a seemingly minor adjustment to a query's criteria can profoundly impact the data returned. If a query that initially fetched a broad set of data is optimized to fetch only a subset (e.g., filtering by status or type for a specific use case), other parts of the application relying on the broader dataset will suddenly receive incomplete information. This leads to unintended side effects of code optimization, where features dependent on the missing data simply disappear from the user interface or fail to activate, all without a single logged error.

The Deceptive Allure of Micro-Optimizations

Micro-optimizations, while sometimes beneficial, can present a deceptive allure. The focus on improving tiny, isolated code segments without a holistic understanding of their impact on the broader system can be a major source of silent bugs. For instance, caching a small part of a database query result or implementing a highly specific filter to save a few milliseconds can drastically alter the data stream for consumers that expected the full, unfiltered dataset. These changes, often made under pressure to meet tight performance targets, might show an immediate, positive benchmark. However, they can introduce subtle semantic shifts that bypass high-level functional tests. This kind of optimization can easily lead to a performance regression testing strategies gap, where the "optimized" code passes its performance benchmark but fails to deliver the full functional scope, resulting in debugging performance related feature failures that are incredibly difficult to diagnose.

Case Study: A Kotlin App's Near-Fatal Performance Tweak

At RelayWorks, we recently encountered a classic example of silent feature disabling within a large-scale Kotlin application. The client, a fintech startup, reported that certain premium features were intermittently unavailable to users, specifically those related to advanced reporting and analytics. The catch: there were no error logs, the features appeared enabled in the admin panel, and direct API calls to those features worked perfectly. Yet, for many users, the corresponding UI elements simply weren't appearing in the application.

The application's architecture was fairly standard for a modern Kotlin service: a multi-module project employing Spring Boot, Kotlin Coroutines for asynchronous operations, and a PostgreSQL database. Data flow typically went from the UI, through a ViewModel, to a Repository layer, and finally to the database. Feature availability was driven by user roles and specific configurations stored in a feature_configs table.

Our initial investigation focused on frontend logic, user permissions, and network issues. Everything seemed correct. The breakthrough came when we looked at recent changes. Approximately two weeks prior, a task was completed to "optimize user dashboard loading time." This task involved several database query optimizations, particularly for endpoints that fetched user-specific configurations and feature flags.

The core issue revolved around how the application determined which features to display to a user. There were two primary mechanisms: a coarse-grained permission check based on user roles (e.g., "Standard," "Premium," "Admin") and a fine-grained feature toggling system stored in the database. The feature_configs table contained entries like (user_id, feature_id, status, category, plan_level). A feature might be ACTIVE but only for plan_level = 'PREMIUM' or category = 'ANALYTICS'.

The "optimized" query was designed to speed up the initial dashboard load by fetching only the "essential" and "active" features for the current user. This was a reasonable goal: reduce payload size and database load for the most frequently accessed data. The developer had correctly identified that loading all possible feature configurations, including inactive or non-essential ones, was overkill for the initial dashboard render. However, the optimization had an unintended, silent side effect that impacted another critical part of the application.

The Original Problem & Solution Attempt

The original problem was a noticeable delay in the user dashboard's initial load time. Profiling revealed that a single, monolithic database query was fetching *all* feature configurations associated with a user, regardless of their current status or category. This query often pulled hundreds or even thousands of rows for power users with access to many features, some of which were inactive or part of optional add-ons not currently subscribed to. This extensive data retrieval and subsequent in-memory filtering was a classic database-bounding scenario, slowing down the UI's responsiveness.

The solution attempt was to narrow down this initial query. The developer modified the Repository layer's getAvailableFeatures(userId) function. Instead of simply selecting all entries for a user_id, the new query included additional WHERE clauses to filter by status = 'ACTIVE' and category IN ('ESSENTIAL', 'REPORTING_BASIC'). The change significantly improved dashboard load times, cutting it by over 400ms, a win that was celebrated and deployed.

The Silent Feature Disablement: What Happened?

The problem emerged because the getAvailableFeatures(userId) function was not only used by the initial dashboard renderer but also by a background service responsible for populating the "Available Upgrades" section and another section displaying "Recently Used Premium Features." These sections relied on a broader set of data: the "Available Upgrades" needed to know about *inactive* features to suggest activation, and "Recently Used Premium Features" needed to display features, even if temporarily deactivated, provided they were linked to a premium plan.

The "optimized" query, by filtering to status = 'ACTIVE' and specific categories, silently removed all inactive features and all features outside 'ESSENTIAL' or 'REPORTING_BASIC' from the dataset returned. While the dashboard loaded faster with only the currently active, essential features, the "Available Upgrades" section now showed nothing, and "Recently Used Premium Features" was empty, even for users who historically used them. Since there were no errors—just missing data—automated functional tests, which typically check for the presence of *active* features, didn't catch the discrepancy. The silent killer had struck.

sequenceDiagram participant User participant UI participant ViewModel participant Repository participant Database User->>UI: Request Feature A UI->>ViewModel: loadFeatureData() ViewModel->>Repository: getFeatureConfig(userId) Repository->>Database: SELECT id, name, type, enabled_status FROM feature_configs WHERE user_id = userId AND status = 'ACTIVE' AND category IN ('ESSENTIAL', 'REPORTING_BASIC') (Optimized Query) Database-->>Repository: Limited Data Set (e.g., only 'ESSENTIAL' and 'ACTIVE' features) Repository-->>ViewModel: Mapped Limited Data ViewModel-->>UI: Update UI UI-->>User: Display Incomplete Feature Set (Missing "Available Upgrades" & "Recently Used Premium Features")

The root cause was a fundamental misunderstanding of the query's usage context. The getAvailableFeatures method, despite its name, was overloaded to serve multiple distinct data requirements. The performance optimization addressed only one of those requirements, at the expense of others. The fix involved refactoring the Repository layer to provide more granular data fetching methods, each tailored to a specific use case, rather than relying on a single, broadly used function.

Specifically, we introduced getDashboardFeatures(userId), getInactiveFeaturesForUpgrade(userId), and getPremiumFeatureHistory(userId). Each of these methods executed a distinct, optimized query that fetched precisely the data needed for its specific purpose. This decoupled the concerns, ensuring that performance optimizations for one area wouldn't inadvertently affect others. This case highlights the importance of thorough data flow analysis and avoiding implicit contracts when optimizing database interactions.

// Original (broader) query concept, implicitly used for multiple purposes
// val allConfigQuery = "SELECT id, name, type, enabled_status, category, plan_level FROM feature_configs WHERE user_id = ?"

// Optimized (narrower) query concept that caused the issue for initial dashboard load
val optimizedDashboardConfigQuery = "SELECT id, name, type, enabled_status FROM feature_configs WHERE user_id = ? AND enabled_status = 'ACTIVE' AND category IN ('ESSENTIAL', 'REPORTING_BASIC')"

// New, specific query for "Available Upgrades"
val inactiveFeaturesQuery = "SELECT id, name, type, enabled_status, category, plan_level FROM feature_configs WHERE user_id = ? AND enabled_status = 'INACTIVE' AND plan_level != 'FREE'"

// Example data mapping
data class FeatureConfig(val id: String, val name: String, val type: String, val enabled: Boolean, val category: String, val planLevel: String)

fun mapResultSetToFeatureConfig(resultSet: ResultSet): List {
    val configs = mutableListOf()
    while (resultSet.next()) {
        configs.add(
            FeatureConfig(
                resultSet.getString("id"),
                resultSet.getString("name"),
                resultSet.getString("type"),
                resultSet.getString("enabled_status") == "ACTIVE",
                resultSet.getString("category"),
                resultSet.getString("plan_level")
            )
        )
    }
    return configs
}

Building Defenses: Strategies to Prevent Silent Bugs

Preventing silent feature disabling from performance optimizations requires a multi-faceted approach, embedding robustness into both development practices and organizational culture. It's not just about writing faster code; it's about writing safer, more predictable faster code. This involves systematic testing, defensive coding, and a proactive approach to understanding code interactions.

Firstly, adopting a "measure twice, cut once" philosophy is paramount. Before embarking on any significant optimization, developers should establish clear baseline metrics, not just for the performance aspect but also for the functional behavior of the system. This includes defining what "correct" behavior looks like across all potentially impacted features. Tools for continuous profiling and monitoring should be standard practice, providing real-time feedback on performance changes and any anomalous behavior.

Secondly, refactoring for clarity and single responsibility is crucial. As seen in the case study, overloaded functions that serve multiple, slightly different data requirements are a major source of hidden bugs during optimization. Developers should strive to create methods that do one thing and do it well, with clearly defined inputs and outputs. This makes it easier to optimize a specific data flow without inadvertently affecting others. For Kotlin applications, this means leveraging idiomatic constructs like extension functions or sealed classes to represent distinct states, ensuring type safety and explicit behavior.

Thirdly, investing in comprehensive performance regression testing strategies is non-negotiable. This goes beyond simple unit tests. It includes integration tests that verify data flow across multiple components and end-to-end tests that simulate real user journeys. When performance optimizations are introduced, these regression tests must be run in addition to any new performance benchmarks. The goal is to catch any functional degradation that might result from a change intended solely for speed.

Finally, fostering a culture of peer review and documentation is essential. Every optimization should be subjected to rigorous code review, with reviewers actively questioning not just the performance gains but also the potential side effects on other parts of the system. Detailed documentation of the "why" behind an optimization, its expected impact, and its potential risks can prevent future developers from making similar mistakes or inadvertently undoing critical logic.

Systematic Performance Validation & Regression Testing

Integrating performance validation and regression testing into the development lifecycle is key to catching silent bugs early. This isn't just about running load tests before release; it's about continuous, automated checks. Every code change, especially one aimed at performance, should trigger a battery of tests:

1. Unit and Integration Tests: These verify the core logic and component interactions.
2. Performance Benchmarks: Specific tests measuring response times, throughput, and resource utilization for the optimized path.
3. Load/Stress Tests: Simulating high user traffic to identify scalability issues and uncover hidden race conditions.
4. Functional Regression Tests: Comprehensive end-to-end tests ensuring that *all* features, even those indirectly related, continue to work as expected with the new code. This is where silent feature disabling is most likely to be detected.

Automated tools should compare results against established baselines and alert teams to any significant deviation, whether a performance degradation or a functional regression. This systematic approach forms a strong defense against the subtle impacts of optimization. For more on this, see Performance Testing Best Practices and Methodologies.

Defensive coding is about anticipating and mitigating potential issues before they become bugs. When optimizing, this means explicitly stating assumptions and validating invariants. In Kotlin, features like require() and check() can enforce preconditions and postconditions, making implicit assumptions explicit. If an optimized query is expected to return a certain type or quantity of data, these assertions can catch discrepancies.

Furthermore, avoiding shared mutable state, especially in concurrent Kotlin Coroutines environments, minimizes opportunities for unexpected side effects. When state must be shared, ensure it's protected by proper synchronization mechanisms or immutable data structures. Designing APIs with explicit contracts about what data they return (e.g., "active features only" vs. "all features for user") clarifies usage and prevents consumers from making incorrect assumptions. This is a core tenet of defensive optimization best practices.

fun processUserData(userId: String, data: String?) {
    // Enforce non-blank user ID - a precondition for most operations
    require(userId.isNotBlank()) { "User ID cannot be blank. Optimization might remove empty IDs." }

    // Ensure data is not null if it's critical for processing
    checkNotNull(data) { "Data to process cannot be null. Optimized data fetching might return null unexpectedly." }

    // ... safe processing logic assuming userId and data are valid
    println("Processing data for user $userId: $data")
}

// Example of a function expecting a specific state from optimized data
fun displayFeatures(features: List) {
    // Assert that the list contains active features, assuming the caller's contract
    check(features.all { it.enabled }) { "Received inactive features where only active were expected." }
    // ... display logic
}

Integrating Performance Tests into CI/CD Pipelines

The most effective way to maintain application health is to integrate performance tests into CI/CD pipelines. This transforms performance validation from a manual, end-of-cycle chore into an automated, continuous process. Every code commit can trigger not only unit and integration tests but also targeted performance benchmarks. This immediate feedback loop allows developers to identify performance regressions or functional side effects of optimization almost instantaneously, making them easier and cheaper to fix.

A robust CI/CD pipeline should include stages for: automated builds, unit tests, integration tests, performance tests (benchmarks, load tests on isolated components), functional regression tests, and finally, deployment to staging/production. Thresholds for performance metrics should be defined, and builds that violate these thresholds (either by slowing down too much or by exhibiting functional regressions) should fail automatically. This proactive approach ensures that speed improvements do not come at the cost of correctness or feature availability.

Need to automate your development workflow? RelayWorks builds custom bots for CI/CD, testing, and more.

Kotlin, with its emphasis on conciseness, safety, and concurrency, offers several language features and architectural patterns that can help prevent silent feature disabling during optimization. Understanding and leveraging these can make optimization a less risky endeavor.

One primary area is the use of Kotlin Coroutines and Flow for concurrent and asynchronous operations. While incredibly powerful for performance, their misuse can introduce subtle timing issues or data race conditions. Proper use of withContext(Dispatchers.IO) for blocking I/O (like database calls) and Dispatchers.Default for CPU-bound work ensures that performance-critical tasks don't starve other operations. However, ensure that when you're passing data between dispatchers or coroutines, the data contract remains intact. If an optimization in an IO dispatcher changes what's returned, consumers on a Default or Main dispatcher must be prepared for that change, or it will manifest as a silent functional bug.

Another safeguard is Kotlin's robust type system. Using sealed classes or interfaces to represent different states or outcomes of an operation can explicitly guide how data is handled. For instance, if a data fetching operation can return Success(data) or Error(reason), any optimization that changes the data structure needs to be reflected in the Success type, ensuring compile-time checks catch discrepancies. Similarly, judicious use of immutable data classes (data class) reduces the chances of unexpected mutations, which are often at the heart of concurrency-related performance bugs.

Finally, Kotlin's extension functions can be a double-edged sword. While they enhance readability and reusability, an extension function introduced for a performance tweak on a common type might inadvertently change behavior across the entire codebase where that type is used. Strict code review and thorough testing are vital when using powerful features like extensions for optimization.

Leveraging Kotlin's Features for Safer Optimizations

Kotlin's features facilitate building more robust and predictable applications, which is crucial for safe optimization. For instance, Flow provides a powerful way to handle streams of data asynchronously. When optimizing a data source (e.g., a database query), ensuring that the Flow emitter contract remains consistent across optimizations is vital. If a Flow previously emitted all items and an optimization causes it to emit only a subset, downstream collectors need to be aware. Using map, filter, and transform operations on Flow explicitly states how data is modified, making changes more transparent.

Furthermore, Kotlin's scope functions (let, run, apply, also, with) can help structure code for readability, but care must be taken that performance-critical sections within these scopes maintain their integrity. For complex optimizations, using typealiased functions or Kotlin Coroutines and Flow documentation to clearly define execution contexts prevents accidental blocking or dispatcher misuse, which can lead to performance issues or silent failures.

import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*
import kotlin.system.measureTimeMillis

// Assume this is an optimized data source (e.g., a database DAO)
fun getOptimizedFeatureFlow(userId: String): Flow = flow {
    println("Fetching optimized features for $userId...")
    delay(50) // Simulate fast database query
    emit(FeatureConfig("feat-A", "Dashboard Analytics", true, "ESSENTIAL", "PREMIUM"))
    emit(FeatureConfig("feat-B", "User Profile Management", true, "ESSENTIAL", "FREE"))
    // Note: 'feat-C' (inactive) and 'feat-D' (advanced) are intentionally omitted for "optimization"
}.flowOn(Dispatchers.IO) // Ensures I/O operations are off the main thread

// Downstream consumer that might expect ALL features
fun processAllFeatures(userId: String) = GlobalScope.launch {
    println("Processing ALL features for $userId...")
    getOptimizedFeatureFlow(userId)
        .onEach { println("Received feature: ${it.name}") }
        .collect {
            // This collector might silently miss 'feat-C' and 'feat-D'
            // and thus fail to display 'available upgrades' or 'advanced options'
        }
    println("Finished processing features for $userId.")
}

data class FeatureConfig(val id: String, val name: String, val enabled: Boolean, val category: String, val planLevel: String)

fun main() = runBlocking {
    val time = measureTimeMillis {
        processAllFeatures("user123").join()
    }
    println("Total time: $time ms")
}

Common Kotlin Performance Anti-Patterns to Avoid

While Kotlin offers many performance advantages, certain anti-patterns can negate these benefits and introduce silent bugs. One common issue is excessive object allocation in tight loops or frequently called functions. While the JVM is efficient, creating numerous short-lived objects (e.g., unnecessary List copies or String concatenations) can lead to GC pressure and unpredictable pauses. Prefer immutable structures where appropriate, but also be mindful of copies.

Another anti-pattern involves improper use of coroutine dispatchers. Performing blocking operations (like traditional synchronous I/O or Thread.sleep()) directly on Dispatchers.Default or Dispatchers.Main can starve thread pools, leading to application unresponsiveness and degraded performance. Always use withContext(Dispatchers.IO) for blocking I/O. Furthermore, excessive launch or async calls without proper structure or cancellation can lead to resource leaks and unexpected background tasks that consume CPU cycles and memory, contributing to Kotlin performance anti-patterns and potential silent resource exhaustion.

import kotlinx.coroutines.*
import java.util.concurrent.atomic.AtomicInteger

// Anti-pattern 1: Excessive mutable shared state without proper synchronization
// This can lead to incorrect results in a concurrent environment, especially if optimized for speed.
object SharedCounterBad {
    var count: Int = 0 // Dangerous!
    fun increment() { count++ }
}

// Corrected with AtomicInteger for thread-safe increments
object SafeCounter {
    val count = AtomicInteger(0)
    fun increment() { count.incrementAndGet() }
}

// Anti-pattern 2: Performing blocking I/O on the default dispatcher
// This can lead to thread starvation and unresponsiveness.
suspend fun fetchDataBlockingBad(): String = coroutineScope {
    // This simulates a blocking call. DO NOT DO THIS on Dispatchers.Default or Main.
    Thread.sleep(1000)
    "Data fetched (blocking)"
}

// Correct way: using Dispatchers.IO for blocking operations
suspend fun fetchDataNonBlockingGood(): String = withContext(Dispatchers.IO) {
    delay(1000) // Simulate non-blocking I/O or a suspendable call
    "Data fetched (non-blocking)"
}

fun main() = runBlocking {
    // Example for Anti-pattern 1
    launch { repeat(1000) { SharedCounterBad.increment() } }
    launch { repeat(1000) { SharedCounterBad.increment() } }
    delay(500) // Give coroutines time
    println("SharedCounterBad final count (potentially wrong): ${SharedCounterBad.count}")

    // Example for safe counter
    launch { repeat(1000) { SafeCounter.increment() } }
    launch { repeat(1000) { SafeCounter.increment() } }
    delay(500)
    println("SafeCounter final count: ${SafeCounter.count.get()}")

    // Example for Anti-pattern 2 (will block if run on a limited dispatcher)
    // println(fetchDataBlockingBad())

    // Example for correct blocking operation handling
    println(fetchDataNonBlockingGood())
}

Beyond Code: The Human Element of Optimization

Technical solutions alone are not enough to prevent silent feature disabling. The human element—how developers think, communicate, and collaborate—plays an equally critical role. Performance optimization often comes with cognitive biases and organizational pressures that can inadvertently lead to these elusive bugs.

Developers, by nature, are problem solvers. When presented with a performance bottleneck, the focus naturally narrows to the identified problem area. This tunnel vision can obscure the broader system context and the ripple effects of a seemingly isolated change. The pressure to deliver quick performance wins can further incentivize this narrow focus, leading to "quick fixes" that don't fully consider the system's intricate dependencies.

Moreover, the "it works on my machine" phenomenon extends to performance. An optimization might behave perfectly in a local development environment with limited data, but reveal its flaws only in production under real-world load and diverse datasets. This discrepancy between local and production environments requires a disciplined approach to testing and validation that transcends individual developer machines.

Effective communication within development teams is paramount. Before embarking on significant optimizations, discussions should involve not just the performance engineers but also product owners, QA specialists, and other developers who might have context on dependent features. This collaborative approach ensures that a holistic view is maintained and potential side effects are considered from multiple perspectives.

Cognitive Biases in Performance Engineering

Several cognitive biases influence how we approach optimization. **Confirmation bias** makes us look for evidence that confirms our optimization worked, often overlooking data that suggests otherwise. **Anchoring bias** can cause us to fixate on a single performance metric (e.g., dashboard load time) while ignoring others (e.g., feature availability). **Sunk cost fallacy** might lead us to persist with a flawed optimization simply because significant effort has already been invested. Recognizing these biases is the first step towards mitigating their impact. Encouraging critical thinking, external validation, and diverse perspectives during code review and post-optimization analysis can help counteract these inherent human tendencies.

Fostering a Culture of 'Verify, Then Optimize'

The most robust defense against silent feature disabling is a proactive culture that prioritizes verification over blind optimization. This means:

1. Baseline Everything: Before any change, understand the current state – both performance and functional.
2. Hypothesize and Test: Formulate clear hypotheses about what an optimization will achieve, and then rigorously test those hypotheses across all dimensions.
3. Holistic Review: Encourage code reviews that question not just the efficiency of the change, but its broader system impact.
4. Blameless Post-Mortems: When bugs inevitably occur, focus on systemic improvements and learning, not blame. This cultural shift ensures that optimization is seen not as a standalone task, but as an integral part of delivering reliable and feature-complete software.Is your team struggling with performance bottlenecks and elusive bugs? Contact RelayWorks for expert guidance. ## Conclusion: Building Resilient, Performant Kotlin Apps

Performance optimization is a critical, ongoing task for any successful Kotlin application, but it demands respect and diligence. The danger of silently disabled features, while subtle, is real and can undermine user trust and business value. By adopting systematic testing, embracing defensive coding principles, integrating performance validation into CI/CD pipelines, and leveraging Kotlin's unique features, developers can build applications that are not only fast but also robust and functionally complete. Remember, true optimization doesn't just make code faster; it makes it reliably faster, ensuring that every feature, intended for your users, remains fully functional and accessible. At RelayWorks, we believe in performance without compromise.