/*
 * V8's architecture revolves around an interpreter (Ignition) and an optimizing compiler (TurboFan).
 * Code first executes in Ignition, collecting type feedback.
 * 'Hot' code (frequently executed) is then sent to TurboFan for highly optimized machine code generation.
 * Understanding this flow guides us to write predictable code.
 */

// Example: A function that will become 'hot' and trigger TurboFan optimization
function calculateSum(a, b) {
    // Ignition interprets this first, collects type information (e.g., 'a' and 'b' are always numbers)
    return a + b;
}

// Repeated execution makes the function 'hot'
for (let i = 0; i < 100000; i++) {
    calculateSum(i, i + 1);
}

// A function that introduces type instability, potentially hindering TurboFan
function processData(value) {
    if (typeof value === 'number') {
        return value * 2;
    } else if (typeof value === 'string') {
        return value.toUpperCase();
    } else {
        return 'Invalid';
    }
}

// Calling with consistent types helps TurboFan
for (let i = 0; i < 100000; i++) {
    processData(i); // All numbers
}

// Calling with inconsistent types might trigger deoptimizations or prevent full optimization
for (let i = 0; i < 100000; i++) {
    if (i % 2 === 0) {
        processData(i); // Numbers
    } else {
        processData('item_' + i); // Strings
    }
}

// Comment: The key takeaway is to write code that consistently provides the same type of input and output
//          for a given function or operation. This predictability allows TurboFan to generate highly
//          specialized and efficient machine code.

/*
 * V8 uses 'hidden classes' (internal maps) to efficiently represent object shapes.
 * Objects with the same shape share a hidden class, allowing V8 to optimize property access.
 * Adding properties in a consistent order maintains hidden class stability (monomorphism).
 * Changing the order or adding properties dynamically creates new hidden classes (polymorphism), leading to slower access.
 */

// GOOD PRACTICE: Initialize all properties in the constructor/at creation
class UserA {
    constructor(id, name, email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }
}

const user1A = new UserA(1, 'Alice', 'alice@example.com');
const user2A = new UserA(2, 'Bob', 'bob@example.com');
// user1A and user2A share the same hidden class, enabling monomorphic property access.

// BAD PRACTICE: Adding properties dynamically or in different orders
class UserB {
    constructor(id, name) {
        this.id = id;
        this.name = name;
    }
}

const user1B = new UserB(1, 'Alice');
user1B.email = 'alice@example.com'; // V8 creates a new hidden class for user1B

const user2B = new UserB(2, 'Bob');
user2B.phone = '555-1234'; // V8 creates yet another new hidden class for user2B
// Property access to user1B.email and user2B.phone becomes polymorphic, slower.

const user3B = new UserB(3, 'Charlie');
user3B.phone = '555-5678';
user3B.email = 'charlie@example.com'; // Even different order impacts hidden class stability.


// Pre-allocate objects for better hidden class management, especially in loops
function createPointsOptimized(count) {
    const points = new Array(count);
    for (let i = 0; i < count; i++) {
        points[i] = { x: i, y: i * 2 }; // All objects created with the same shape and properties at once
    }
    return points;
}

function createPointsSuboptimal(count) {
    const points = [];
    for (let i = 0; i < count; i++) {
        const p = {};
        p.x = i;
        p.y = i * 2;
        points.push(p); // Properties added dynamically, but consistently within the loop, which is still better than varying order.
                       // However, initializing directly in literal form is often preferred.
    }
    return points;
}

/*
 * Inline Caches (ICs) store information about the types of arguments and receivers
 * seen by a function or operation. This allows V8 to quickly execute subsequent calls
 * if types are consistent (monomorphic IC).
 * Inconsistent types (polymorphic or megamorphic ICs) force V8 to perform slower lookups.
 */

// GOOD PRACTICE: Functions that consistently receive and return the same types
function addNumbers(a, b) {
    // V8 creates a monomorphic IC for 'a' and 'b' being numbers.
    return a + b;
}

// All calls with numbers: highly optimized
for (let i = 0; i < 100000; i++) {
    addNumbers(i, i + 0.5);
}

// BAD PRACTICE: Functions receiving inconsistent types (polymorphic)
function processValue(val) {
    // This will create a polymorphic IC as 'val' can be number or string.
    // V8 has to check the type on each call, leading to slower execution.
    if (typeof val === 'number') {
        return val * 10;
    } else {
        return val + ' processed';
    }
}

// Calls with mixed types: less optimized
for (let i = 0; i < 100000; i++) {
    if (i % 2 === 0) {
        processValue(i);
    } else {
        processValue(String(i));
    }
}

// Avoiding mixed array types
function sumArray(arr) {
    let sum = 0;
    for (let i = 0; i < arr.length; i++) {
        sum += arr[i]; // If arr[i] can be number or string, this operation becomes polymorphic.
    }
    return sum;
}

const numbersOnly = [1, 2, 3, 4, 5];
sumArray(numbersOnly); // Monomorphic, fast

const mixedArray = [1, '2', 3, '4'];
sumArray(mixedArray); // Polymorphic, slower for the '+' operation due to type coercion.

// Comment: Strive for monomorphic operations wherever possible. Keep function signatures and array contents type-consistent.

/*
 * Loops and array manipulations are critical performance bottlenecks.
 * V8 can heavily optimize simple, predictable loops.
 * Avoid operations that can trigger deoptimizations within hot loops.
 * Leverage built-in array methods (map, filter, reduce) as they are often implemented in C++ and highly optimized.
 */

// GOOD PRACTICE: Simple 'for' loop, pre-calculating length, consistent types
function sumArrayClassic(numbers) {
    const len = numbers.length; // Cache length
    let sum = 0;
    for (let i = 0; i < len; i++) {
        sum += numbers[i]; // Consistent numeric operation
    }
    return sum;
}

const data = Array.from({ length: 1000000 }, (_, i) => i);
sumArrayClassic(data);

// Using optimized built-in methods
function sumArrayBuiltIn(numbers) {
    return numbers.reduce((acc, current) => acc + current, 0);
}
sumArrayBuiltIn(data);

// BAD PRACTICE: Deoptimizing operations within a hot loop
function processItemsWithDynamicObject(items) {
    for (let i = 0; i < items.length; i++) {
        const item = items[i];
        // Dynamically adding properties or calling methods that change hidden classes within a loop
        // is a significant deoptimization trigger.
        if (item.value % 2 === 0) {
            item.processed = true; // Avoid adding new properties in a hot loop
        }
    }
}

const items = Array.from({ length: 1000000 }, (_, i) => ({ value: i }));
// Initial call will run slowly for optimization, subsequent calls might deoptimize if 'processed' property
// creates a new hidden class each time for different objects.
processItemsWithDynamicObject(items);

// Another BAD PRACTICE: Modifying array length dynamically in a hot loop (rare but possible)
function dynamicLoopModification(arr) {
    for (let i = 0; i < arr.length; i++) {
        if (arr[i] === undefined) {
            arr.push(i); // Modifying array length invalidates V8's assumptions, often leading to deoptimization.
        }
    }
}

// Comment: Prioritize simple 'for' loops for extreme performance, or native built-in methods.
//          Avoid dynamic property additions/deletions or array length changes inside critical loops.

/*
 * Modern JavaScript features (e.g., destructuring, spread, async/await) enhance readability and expressiveness.
 * While V8 continually optimizes them, understanding their underlying mechanics helps in responsible usage.
 * Avoid excessive or complex use that might hinder V8's ability to optimize.
 */

// GOOD PRACTICE: Simple destructuring for clarity and reasonable performance
function getUserInfo({ name, age }) {
    console.log(`Name: ${name}, Age: ${age}`);
}
const userProfile = { name: 'Alice', age: 30, city: 'NY' };
getUserInfo(userProfile);

// GOOD PRACTICE: Spread for shallow cloning or merging, often optimized
const originalArray = [1, 2, 3];
const clonedArray = [...originalArray]; // Efficient shallow clone

const obj1 = { a: 1, b: 2 };
const obj2 = { c: 3, d: 4 };
const mergedObj = { ...obj1, ...obj2 }; // Efficient merging

// Responsible Async/Await usage
async function fetchDataAndProcess() {
    try {
        const response = await fetch('https://api.example.com/data');
        const data = await response.json();
        // Process data (perform CPU-bound tasks outside the async function if possible)
        return data;
    } catch (error) {
        console.error('Error fetching data:', error);
    }
}
// fetchDataAndProcess(); // Activates efficient asynchronous flow via microtasks

// POTENTIALLY SUBOPTIMAL (depending on V8 version and context): Deeply nested or highly dynamic destructuring in hot paths
function extractDeepData({ user: { address: { street, zip } } }) {
    // While readable, complex destructuring in very hot loops might incur minor overhead.
    // Simpler property access might be marginally faster if micro-optimizing.
    console.log(`Street: ${street}, Zip: ${zip}`);
}

const complexData = {
    user: { id: 123, address: { street: 'Main St', zip: '12345' } }
};
extractDeepData(complexData);

// Comment: Use modern features, but be mindful in extreme hot paths. Prioritize clarity and correctness first.
//          V8's continuous improvements mean many of these are highly optimized.

/*
 * V8's TurboFan generates highly optimized code based on assumptions about runtime behavior (e.g., consistent types, stable object shapes).
 * When these assumptions are violated, V8 'deoptimizes' by discarding the optimized code and reverting to slower interpreted or less optimized code.
 * Identifying and eliminating these triggers is crucial for sustained performance.
 */

// COMMON DEOPTIMIZATION TRIGGER: 'try...catch' blocks inside hot functions
// V8 finds it difficult to optimize code paths that can jump unpredictably due to exceptions.
function calculateWithCatch(a, b) {
    try {
        return a / b; // This entire function might not be fully optimized if 'b' can be 0 and trigger an error.
    } catch (e) {
        console.error(e);
        return 0;
    }
}

// GOOD PRACTICE: Isolate try...catch blocks to non-hot code or wrapping calls
function performCalculation(a, b) {
    return a / b; // This function can be highly optimized.
}

function guardedCalculation(a, b) {
    try {
        return performCalculation(a, b);
    } catch (e) {
        console.error(e);
        return 0;
    }
}

// ANOTHER TRIGGER: The 'delete' operator on optimized objects
// 'delete' changes the hidden class of an object, leading to deoptimization.
const myObject = { a: 1, b: 2 }; // V8 optimizes access to 'a' and 'b'
delete myObject.a; // Deoptimizes operations on myObject and potentially functions that access its properties.

// GOOD PRACTICE: Nullify properties instead of deleting them if property presence is not critical.
// Or, reconstruct the object without the property if structural change is required.
const anotherObject = { x: 1, y: 2 };
anotherObject.x = null; // Keeps the hidden class stable.

// TRIGGER: Usage of 'arguments' object (modern JS prefers rest parameters)
function sumArgs() {
    let total = 0;
    for (let i = 0; i < arguments.length; i++) {
        total += arguments[i]; // 'arguments' object is an 'array-like' object, hinders optimization.
    }
    return total;
}

// GOOD PRACTICE: Use rest parameters for better optimization
function sumRest(...args) {
    let total = 0;
    for (const arg of args) {
        total += arg;
    }
    return total;
}

// TRIGGER: 'eval()' or 'with' statement (highly discouraged anyway for security and readability)
// These constructs prevent V8 from making many assumptions at compile time.

// Comment: Proactively identify and refactor code that uses these patterns, especially in hot code paths.