Forem: Mitchell

The Rendering Machine: Understanding the Critical Rendering Path

Mitchell — Thu, 24 Apr 2025 08:57:13 +0000

The Rendering Machine: Understanding the Critical Rendering Path

This post delves into the Critical Rendering Path (CRP).

The Rendering Machine: Understanding the Critical Rendering Path
Table of Contents
The Critical Rendering Path (CRP)
- Why is the CRP Critical? / Why Optimize It?
- What is the Rendering Strategy?
- Progressive Rendering
- Why is it Progressive?
- When is it Too Early or Too Late to Render?
- What Can Block Rendering and Hurt Performance?
- Resources on the Critical Path
  - Types of Blocking Resources
  - Identifying Blocking Resources
- Is Resource Blocking Necessary?
- General Tips for Optimizing the CRP
- Key Components of the CRP
- DOM (Document Object Model)
- CSSOM (CSS Object Model)
  - CSS Selectors
- Render Tree
- Layout (Reflow)
- Paint (Repaint)
Alternative Perspectives: The Key Path
Tools for Analysis
Related Questions
References

The Critical Rendering Path (CRP)

Short Answer: The sequence of steps the browser takes to convert HTML, CSS, and JavaScript into pixels on the screen, using the minimum necessary resources to display initial content.

Long Answer (Abstraction Levels): The process spans multiple levels of abstraction:

Bits
Bytes
Characters
Tokens
Nodes
DOM / CSSOM
Render Tree
Layout
Paint
Composite
Web Page (Pixels on Screen)

Longer Answer (The Steps): The rendering path typically involves these steps:

Constructing the Document Object Model (DOM) from the HTML source code.
Constructing the CSS Object Model (CSSOM) from the CSS rules.
Executing JavaScript that might modify the DOM or CSSOM.
Combining the DOM and CSSOM into the Render Tree.
Performing Layout (or "Reflow") to calculate the exact size and position of each object in the render tree.
Painting the pixels for each element onto layers (often in memory).
Compositing the various layers together and displaying them on the screen.

Why is the CRP Critical? / Why Optimize It?

Optimizing the CRP is crucial because it helps to:

Improve rendering performance metrics like First Contentful Paint (FCP) and Largest Contentful Paint (LCP), leading to a faster perceived load time.
Ensure smooth animations and scrolling (aiming for 60 frames per second).
Improve responsiveness to user interactions (reducing input delay).
Avoid jank (stuttering or lag during rendering or interaction).

What is the Rendering Strategy?

Progressive Rendering

Browsers employ progressive rendering, meaning they typically start rendering the page as soon as they have enough resources, rather than waiting for everything to download.

Why is it Progressive?

Unlike native software, which is often fully installed before running (loading all necessary resources like images, audio, code upfront), browsers operate differently. The web is inherently distributed; a browser doesn't know all the resources a page needs until it starts parsing the HTML. Downloading everything beforehand isn't feasible. Therefore, browsers render content progressively as resources arrive and are processed.

When is it Too Early or Too Late to Render?

Too early: If the browser renders HTML immediately, before essential CSS or JavaScript has been processed, the page might initially look broken or unstyled (a "Flash of Unstyled Content" or FOUC). It might then change significantly as styles and scripts are applied, creating a jarring experience.
Too late: If the browser waits for absolutely all resources (including non-critical ones like images far down the page) before rendering anything, users face a blank screen for an extended period, leading to a poor user experience and potentially high bounce rates.

What Can Block Rendering and Hurt Performance?

To understand potential bottlenecks, we must identify the resources involved in the CRP and how they can block progress.

Resources on the Critical Path

The browser prioritizes critical resources, waiting for them before completing the initial render. Non-critical resources are often deferred or loaded asynchronously.

Critical resources typically include:

The HTML document itself (at least the initial part).
Render-blocking CSS (usually stylesheets linked in the <head> without specific attributes to defer them).
Render-blocking JavaScript (usually scripts in the <head> that are not marked async or defer).

Note: The browser processes HTML in a streaming fashion. It starts parsing and potentially requesting linked resources as soon as it receives chunks of the HTML.

Non-critical resources often include:

Images (though they can cause layout shifts if space isn't reserved).
Fonts (can cause Flash of Invisible Text (FOIT) or Flash of Unstyled Text (FOUT), and layout shifts).
JavaScript marked async or defer, or placed just before the closing </body> tag.
CSS with a media attribute that doesn't match the current device (e.g., media="print" or media="(max-width: 480px)" on a desktop).

Note: Late-loading resources like fonts and images can cause content to shift after initially rendering. The Cumulative Layout Shift (CLS) metric measures this visual instability.

Types of Blocking Resources

Short Answer:

There are two main types:

Render-blocking resources: Critical resources (like CSS by default) that pause the browser's rendering process (specifically, render tree construction and painting) until they are downloaded and processed.
Parser-blocking resources: Resources (like synchronous JavaScript by default) that stop the browser's HTML parser from continuing to process the rest of the document.

Parser-blocking resources are inherently also render-blocking, since content must be parsed before it can be rendered. Blocking the parser is often more detrimental to performance than blocking rendering alone.

Long Answer:

Render-blocking resources (e.g., standard CSS linked in <head>) block the construction of the render tree and subsequent painting. However, the HTML parser might continue processing the document while the CSS is being downloaded and parsed (using the preload scanner). CSS linked in the <head> typically blocks rendering of the entire page until the CSSOM is constructed.

CSS is render-blocking by default. It can be made non-blocking for specific conditions using the media attribute (e.g., <link rel="stylesheet" href="..." media="print">). Developers can also explicitly mark resources using blocking="render".

Parser-blocking resources (e.g., synchronous JavaScript) halt the main HTML parser. This prevents the browser from discovering other resources further down the HTML until the script is downloaded, parsed, and executed. Consequently, rendering is also blocked. > Synchronous JavaScript is parser-blocking by default. Use the async or defer attributes on <script> tags to make it non-blocking.

The browser often employs a secondary HTML parser, the preload scanner, which scans ahead while the main parser is blocked (e.g., by a script). This allows the browser to discover resources like images, CSS, and other scripts further down the page and start downloading them speculatively, potentially saving time.

Identifying Blocking Resources

Tools like WebPageTest, Lighthouse (in Chrome DevTools), and the Performance tab in browser developer tools can help identify render-blocking resources in the network waterfall chart.

Is Resource Blocking Necessary?

Yes, to some extent.

If the browser rendered HTML without waiting for essential CSS for styling or critical JavaScript that might alter structure or content, it would likely display a broken or unstyled page (FOUC). This leads to a poor user experience as the page reflows and restyles significantly once those critical resources load. The blocking mechanism ensures a more stable initial render, albeit at the cost of waiting for those resources.

General Tips for Optimizing the CRP

Minimize Critical Resources: Reduce the number of resources marked as critical. Defer the download of non-essential resources, mark scripts with async or defer, inline critical CSS for above-the-fold content, or eliminate unused resources entirely.
Optimize Resource Size and Request Count: Reduce the total number of network requests for critical resources (e.g., via bundling) and minimize the file size of each resource (e.g., through minification, compression, removing unused code, using efficient formats).
Optimize Loading Order: Prioritize the loading of critical assets needed for the initial viewport (above-the-fold content). Ensure they are discovered, downloaded, and processed as early as possible to shorten the CRP length (e.g., using <link rel="preload">).

Key Components of the CRP

DOM (Document Object Model)

What:

A tree-like data structure representing the hierarchy of HTML elements/tags in a document.
It's built incrementally as the browser parses the HTML: Bytes -> Characters -> Tokens -> Nodes -> DOM Tree.

Performance Implications:

Deeply nested HTML or an excessive number of elements can slow down DOM construction. A large DOM tree also makes subsequent steps like style calculation and layout more computationally expensive, potentially contributing to jank or sluggishness.

CSSOM (CSS Object Model)

What:

Similar to the DOM, it's a tree-like data structure, but it represents the styles associated with the DOM elements. It includes styles from browser defaults, user-defined stylesheets, and inline styles.
Unlike the DOM, the final CSSOM is often considered non-incremental in its application. Because CSS rules can override each other based on specificity and order (the "Cascade"), the browser typically needs to process all applicable CSS rules to determine the final computed style for each node before proceeding to layout.
This requirement is why CSS is considered render-blocking by default.

CSS Selectors

Browsers typically match CSS selectors efficiently, often starting from the rightmost component (the "key selector") and working leftwards, checking against the DOM tree. While selector complexity can impact performance:

The performance difference between simple and complex selectors is usually minimal (microseconds). Optimizing selectors rarely yields significant gains.
Highly specific selectors might require slightly more DOM traversal.
Measure first, optimize only if profiling shows a bottleneck. Focus on broader CSS optimizations like reducing file size and removing unused rules.
See MDN's CSS Performance Optimization Guide for more details.

Render Tree

What: A tree-like structure formed by combining the DOM and CSSOM. It represents only the elements that will be visually rendered on the page.

When: Constructed after both the DOM and CSSOM are available.

How: The browser traverses the DOM tree. For each visible node, it finds the matching CSSOM rules and calculates the computed styles.

Note:

The Render Tree excludes non-visual elements, such as tags within <head>, elements hidden with display: none, and their descendants. (Elements hidden with visibility: hidden are included as they still take up space).

Layout (Reflow)

What: The process of calculating the exact size and position of each element in the render tree within the viewport.

When: Occurs after the Render Tree is constructed. It also happens whenever the geometry of elements might change.

Determining Size and Position:

The viewport size is crucial. Without specific meta tags, mobile browsers often use a default layout viewport width (e.g., 960px). Using <meta name="viewport" content="width=device-width"> sets the layout viewport width to the device's screen width.
Layout (or Reflow) recalculates element positions and dimensions. This is triggered by: changes to the viewport size (resizing the browser window, changing device orientation), changes to the DOM (adding/removing elements), changes to CSS properties affecting geometry (width, height, margin, padding, font-size, position), or requesting certain geometric properties in JavaScript (offsetTop, clientWidth).

Impacting Factors:

The number of nodes in the render tree: More nodes mean more calculations.
Complexity of styles affecting layout.
Frequent triggers (e.g., animating layout properties like width or top in JavaScript).

Performance: Layout can be a significant performance bottleneck, especially with large DOMs or frequent updates. Forcing layout repeatedly in JavaScript ("Layout Thrashing") can cause severe jank, particularly during scrolling or animations.

Optimization Strategy: Minimize and batch layout operations.

Avoid querying layout-triggering properties repeatedly in loops. Read values first, then write changes.
Use CSS transform and opacity for animations whenever possible, as they often don't trigger layout and can be handled more efficiently by the compositor.

Paint (Repaint)

What: The process of filling in the actual pixels for each element based on the calculated layout and styles (color, background, borders, text, shadows, etc.). Painting occurs onto layers.

When: After Layout. It also happens when visual styles change without affecting layout (e.g., changing background-color, color, box-shadow).

Stages:

Initial paint: The entire visible screen area is painted.
Repaint: Subsequent updates ideally only repaint the specific areas (layers) that changed.

Impacting Factors:

Complexity of visual styles (e.g., complex gradients, shadows).
The size of the area that needs to be repainted.

Performance: While painting takes time, it's often less likely to be the primary bottleneck compared to frequent or complex Layout operations. However, very complex paint operations (like intricate shadows or gradients on large areas) can still impact performance, especially on low-powered devices.

Optimization Strategy: Simplify paint complexity and reduce painted areas where possible.

Promote elements that animate frequently to their own compositor layer using will-change or transform: translateZ(0) (use judiciously).
Simplify complex styles if profiling indicates a paint bottleneck.
Measure first using browser developer tools (Performance tab) to identify paint costs before optimizing.

Alternative Perspectives: The Key Path

As user-centric performance metrics like LCP (Largest Contentful Paint) and FCP (First Contentful Paint) have emerged, an alternative view sometimes discussed is the Key Path (or Contentful Rendering Path).

This perspective emphasizes that even resources not strictly render-blocking according to the CRP definition (like the main image needed for LCP) should be prioritized if they are essential for rendering meaningful content quickly. Optimizing the Key Path involves ensuring these crucial content elements are loaded and rendered promptly.

Tools for Analysis

Tools for measuring webpage performance and diagnosing CRP issues:

WebPageTest.org
Lighthouse (available in Chrome DevTools and as a standalone tool/API)
Chrome DevTools (Performance tab, Network tab)
Firefox Developer Tools (Performance tab, Network tab)

References

My Learning Notes: Choosing the Right AI Model and Hardware

Mitchell — Mon, 21 Apr 2025 09:43:03 +0000

My Learning Notes: Choosing the Right AI Model and Hardware

The Core Challenge: Model vs. Hardware

At its heart, the relationship is simple:

Bigger, more capable models generally require more powerful hardware.
The most critical hardware resource for running Large Language Models (LLMs) is usually GPU Memory (VRAM).

If you try to run a huge model on a GPU with too little VRAM, it either won't work or will be incredibly slow (if it tries to use system RAM, which is much slower for these tasks).

Understanding the Model Side

When looking at models, especially on places like Hugging Face or when using tools like Ollama, a few key things determine their resource needs:

Parameter Count (e.g., 7B, 13B, 70B):

- This is roughly the "size" or "complexity" of the model's brain. 'B' stands for billions of parameters.
- **More parameters generally mean the model _might_ be smarter**, better at understanding nuance, and have more knowledge.
- **BUT, more parameters directly translate to needing more VRAM and disk space.**

Quantization (e.g., FP16, Q8_0, Q5_K_M, Q4_0):

- Think of this like compressing a file. Quantization reduces the precision used to store the model's parameters (its numbers).
- **Why do it?** To make the model smaller! A quantized model takes up less disk space and, crucially, less VRAM. This allows bigger models (more parameters) to run on less powerful hardware.
- **The Trade-off:** Reducing precision _can_ reduce the model's performance and accuracy. It might make slightly dumber mistakes or lose some nuance. The goal is to find a balance.
- **Common Types:**
  - `FP16` (Float Precision 16-bit): Half-precision. Often the baseline before quantization. Good quality, but larger VRAM needs.
  - `Q8_0` (Quantized 8-bit): Uses 8 bits per parameter. Generally very little quality loss compared to FP16, but half the size.
  - `Q4_K_M`, `Q5_K_M`, etc. (Quantized 4-bit, 5-bit, etc.): Use even fewer bits. Offer significant size reduction, making larger models accessible on consumer GPUs. `_K_M` variants are often preferred as they use clever techniques to maintain quality better than simpler `_0` or `_1` types at the same bit level.
  - `Q2`, `Q3` (Quantized 2/3-bit): Extreme quantization. Very small, but often come with a significant and sometimes unpredictable drop in quality.

Model Version/Architecture:

- Newer models (like Qwen 2.5 vs Qwen 1.5, or Llama 3 vs Llama 2) often perform better than older models _of the same size_. This is usually thanks to better training techniques, more data, or improved architectures.

Training vs. Inference:
- Inference: Just running the model to get answers. This is what most people do locally. VRAM needs depend mainly on model weights and conversation context (KV Cache).
- Training/Fine-tuning: Teaching the model new things or adapting it. This requires much more VRAM because you need to store not just the weights, but also gradients and optimizer states (intermediate calculations). We won't focus much on training here, as inference is the more common starting point.

Understanding the Hardware Side (Especially VRAM for Inference)

So, how much VRAM do you actually need to run a model (inference)? It mainly comes down to storing a few key things on the GPU:

Model Weights: This is usually the biggest chunk. The VRAM needed depends directly on the parameter count and the quantization level.

- **Rough Calculation:** `VRAM for Weights (GB) ≈ (Number of Parameters in Billions * Bits per Parameter) / 8`
- _Example (7 Billion Parameter Model):_
  - `FP16 (16-bit)`: (7 \* 16) / 8 = 14 GB
  - `Q8_0 (8-bit)`: (7 \* 8) / 8 = 7 GB
  - `Q4_K_M (≈4-bit)`: (7 \* 4) / 8 = 3.5 GB
  - `Q2_K (≈2-bit)`: (7 \* 2) / 8 = 1.75 GB

KV Cache (Key-Value Cache): This is memory used to keep track of the conversation context. Without it, the model would have to re-read the entire chat history for every single new word it generates!

- **Its size depends heavily on:**
  - **Context Length:** How much conversation history the model can handle (e.g., 4096 tokens, 32k tokens). Longer context = bigger KV cache needed.
  - **Batch Size:** How many requests you're processing at the same time. Each simultaneous request needs its own KV cache.
- **Impact:** The KV cache can easily take up several GBs of VRAM, sometimes even more than the model weights, especially with long contexts! This is often the bottleneck when trying to run models with long context windows or handle multiple users.

Overhead: Some VRAM is always used by the GPU driver, the model loading libraries (like llama.cpp used by Ollama), and the inference engine itself. Budget maybe 1-2GB+ for this.

Putting it Together (Example Estimate):

Let's try to estimate VRAM for running a 7B Q4_K_M model (≈4-bit) with a standard 4096 token context length for a single user:

Weights: ≈ 3.5 GB
KV Cache (Estimate for 4096 context): Maybe 4-8 GB (this varies a lot!)
Overhead: ≈ 1.5 GB
Total Estimated VRAM: 3.5 + 6 (mid-estimate) + 1.5 = ~11 GB

Key Takeaway: Even a relatively small 7B model, quantized to 4-bit, can push the limits of lower-VRAM GPUs (like 8GB cards) once you factor in the KV cache for a decent context length. A 16GB card might be tight, while 24GB offers more breathing room. Running multiple requests concurrently would need even more VRAM, primarily due to multiple KV caches.

Making the Choice: Common Trade-offs

Based on community discussions and benchmarks, here are some general pointers I've picked up when VRAM is limited:

More Parameters vs. Less Quantization?
- General wisdom suggests that a larger model with more quantization often performs better than a smaller model with less quantization, up to a point. For example, a 14B model at Q4 might be better than a 7B model at Q8 or FP16, assuming they fit in your VRAM.
- Sweet Spot: Quantization levels like Q4_K_M and Q5_K_M seem to offer a great balance of size reduction and performance preservation for many models.
- Avoid Extremes: Q2 and Q3 quantizations can lead to significant performance drops and unpredictable behavior. It might be better to run a smaller model at Q4 than a larger one at Q2. Diminishing returns often hit hard above Q5 – the quality gain from Q6 or Q8 might not be worth the extra VRAM unless you have specific needs and plenty of memory.
Newer vs. Older Models: As mentioned, newer architectures or versions trained on more data (like Gemma 2 vs Gemma 1, or Llama 3 vs Llama 2) often provide better results even if the parameter count is similar or slightly smaller than an older model.
Accuracy vs. Speed: Smaller models and more heavily quantized models generally run faster (generate tokens per second quicker). You trade off some potential quality for speed.

Don't Forget System RAM and CPU!

While VRAM is critical, your regular computer memory (RAM) and processor (CPU) still play important roles:

System RAM:
- Needed to initially load the model file from disk before transferring it to VRAM.
- Used by the operating system, background tasks, and the application serving the model (like Ollama or a FastAPI app).
- Handles data processing (like reading input text).
- Rule of Thumb: Having at least as much RAM as the unquantized size of the model is a safe starting point (e.g., ~14GB RAM for a 7B model, so 16GB minimum, 32GB better). You'll need more if processing large datasets or handling many requests.
CPU:
- Orchestrates the whole process.
- Handles tasks like text tokenization (breaking words into pieces the model understands), running the web server, managing requests.
- A reasonably modern multi-core CPU is needed, but for inference, the GPU is usually the bottleneck. (For training, a faster CPU becomes more important).

Tools Matter Too (Briefly)

Tools like Ollama make running models easy. More advanced inference engines like VLLM are specifically designed for high performance (more requests per second, better VRAM usage via techniques like PagedAttention), but might be more complex to set up. For starting out, Ollama is great. If you need maximum performance later, exploring alternatives like VLLM might be worthwhile.

A Quick Guide to GGUF Quantization Types (Common Ones)

When using Ollama or llama.cpp, you'll often see GGUF files with names indicating the quantization. Here's a rough quality/size hierarchy (from smallest/lowest quality to largest/highest quality):

Q2_K: Extreme quantization (2-bit). Smallest size, highest potential quality loss. Use only if severely VRAM limited.
Q3_K_S, Q3_K_M, Q3_K_L: Aggressive (3-bit). Better than Q2, but still significant potential quality loss. _L is best within 3-bit.
Q4_0, Q4_1: Basic 4-bit. Decent size reduction. Newer _K methods are usually preferred.
Q4_K_S, Q4_K_M: Popular Choice (4-bit). Excellent balance between size, VRAM usage, and quality. _M is slightly larger/better than _S. Great starting point.
Q5_0, Q5_1: Basic 5-bit.
Q5_K_S, Q5_K_M: Popular Choice (5-bit). Slightly better quality than Q4_K for slightly more VRAM/size. _M is preferred. Often worth it if Q4_K_M fits comfortably.
Q6_K: High Quality (6-bit). Noticeably larger than Q5_K. Good option if you have plenty of VRAM and want quality closer to Q8.
Q8_0: Near Lossless (8-bit). Very close to FP16 quality. Requires double the VRAM of Q4. Good for production quality if hardware allows.
FP16: Half Precision (16-bit). No quantization loss (from original FP16 model). Baseline for quality comparison. Requires the most VRAM among common inference types.
FP32: Full Precision (32-bit). Rarely used for inference due to huge size. Mostly relevant during training.

Recommendation: For a typical 7B or 13B model on consumer GPUs (like those with 16GB or 24GB VRAM), starting with Q4_K_M or Q5_K_M is usually the best bet.

Case Study: Deploying a Python AI Application with Ollama and FastAPI

Mitchell — Mon, 21 Apr 2025 09:05:06 +0000

Case Study: Deploying a Python AI Application with Ollama and FastAPI

An AI project built locally, perhaps using powerful tools like Ollama and FastAPI, eventually needs deployment to a server for wider access or reliable 24/7 operation. This document details a common process for deploying such a Python-based AI application onto a Linux server.

The steps cover connecting to the server, setting up the environment, managing AI models, running the application manually for testing, and configuring it to run reliably as a background service using system. While the steps are based on deploying an application using FastAPI and Ollama, many illustrate standard deployment practices applicable to various Python web applications.

Case Study: Deploying a Python AI Application with Ollama and FastAPI
- Table of Contents
- Connecting to the Server via SSH
- Generating SSH Keys
- Connecting
- Cloning the Project Repository
- Environment Setup
- 1. Installing uv (Optional but Recommended)
- 2. Installing Python
- 3. Installing Software Dependencies
  - Project Dependencies
  - Installing and Running Ollama
- 4. Preparing the AI Models
  - Uploading/Downloading Models
  - Building Models with Ollama
- 5. Setting Up Environment Variables
- 6. Running the Project Manually (Testing)
- Deploying as a Service with systemd
- Creating the Service File
- Enabling and Starting the Service
- Frequently Encountered Issues (FAQ)
- Environment Configuration Issues
- Runtime Issues
- Conclusion

Connecting to the Server via SSH

Secure Shell (SSH) is the standard method for securely connecting to and managing remote Linux servers. This is typically the first step in the deployment process.

Generating SSH Keys

If you don't already have an SSH key pair on your local machine, you'll need to generate one: a private key (kept secure locally) and a public key (shared with the server).

Use the ssh-keygen command on your local machine. Following the prompts is usually sufficient. Common algorithms are ED25519 (recommended) or RSA.

# Example using ED25519
ssh-keygen -t ed25519 -C "your_email@example.com"
# Follow the prompts to save the key (default location is usually fine) and optionally set a passphrase.

Reference: GitHub Docs: Generating a new SSH key

On macOS and Linux, keys are typically stored in the ~/.ssh directory. Use ls -al ~/.ssh to check:

id_ed25519 or id_rsa: The private key. Never share this file.
id_ed25519.pub or id_rsa.pub: The public key. Copy the contents of this file to provide to the server administrator or add it yourself if you have access.

The server administrator (or you) must add the contents of your public key file (id_xxx.pub) to the ~/.ssh/authorized_keys file within the target user's home directory on the server.

Connecting

Once your public key is authorized on the server, you can establish a connection using your private key:

ssh -i /path/to/your/private_key your_server_username@your_server_hostname_or_ip -p <ssh_port_number>

Replace the placeholders:

/path/to/your/private_key: The path to your private key file (e.g., ~/.ssh/id_ed25519).
your_server_username: Your username on the remote server.
your_server_hostname_or_ip: The server's IP address or resolvable hostname.
<ssh_port_number>: The SSH port number configured on the server (default is 22, but often changed for security).

Note: Omit the angle brackets (<>) when replacing placeholders like <ssh_port_number>.

On the first connection to a new server, you'll likely see a host authenticity warning. This is normal. Type yes to proceed.

The authenticity of host '...' can't be established.
... key fingerprint is ...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Cloning the Project Repository

With a successful SSH connection, get your project code onto the server using Git:

git clone your_repository_link
# Example: git clone git@github.com:your_username/your_project.git
# Or: git clone https://github.com/your_username/your_project.git

Replace your_repository_link with the actual SSH or HTTPS URL of your Git repository. Navigate into the cloned directory: cd your_project_directory_name.

Environment Setup

Set up the necessary software and environment on the server.

1. Installing `uv` (Optional but Recommended)

uv is a very fast Python package installer and resolver written in Rust. Using it can significantly speed up dependency installation compared to standard pip. It's optional, but recommended.

# Using pip to install uv (ensure pip is available)
pip install uv
# Alternatively, follow official instructions: https://github.com/astral-sh/uv#installation

Verify the installation:

uv --version
# Expected output similar to: uv x.y.z

2. Installing Python

Ensure a compatible Python version (e.g., 3.8-3.11, check your project's needs) is installed.

If you installed uv, you can use it to install Python:

# Replace 3.x.y with your target version (e.g., 3.10.13)
uv python install 3.x.y
# Follow any prompts regarding PATH updates.

Alternatively, use the system's package manager (common on Linux servers):

# Example for Debian/Ubuntu
sudo apt update
sudo apt install python3 python3-pip python3-venv

# Example for CentOS/RHEL
sudo yum update
sudo yum install python3 python3-pip

Confirm the Python installation:

python3 --version
# Or sometimes just 'python --version' depending on PATH setup

Reference: Installing Python with uv

3. Installing Software Dependencies

Project Dependencies

Your project should have a requirements.txt file listing Python dependencies. Navigate to your project directory and install them.

Using uv (recommended if installed):

cd /path/to/your/project
uv pip install -r requirements.txt

Alternatively, using pip (usually within a virtual environment):

cd /path/to/your/project
# Best practice: Create and activate a virtual environment first
# python3 -m venv venv
# source venv/bin/activate
pip install -r requirements.txt
# Or pip3 install -r requirements.txt

Note: Replace /path/to/your/project with the actual absolute path to your cloned repository.

Installing and Running Ollama

Ollama allows running large language models locally. Install it on the Linux server using the official script:

curl -fsSL https://ollama.com/install.sh | sh

For initial testing, you can start the Ollama server manually in the background:

ollama serve & # The '&' runs it in the background for the current session only.

Note: For production, Ollama should be set up as a systemd service (the installation script often does this automatically, check with systemctl status ollama). Running ollama serve & is primarily for temporary testing.

Verify Ollama is running and accessible (this command talks to the running server):

ollama list
# Should show an empty list or any models already pulled/created.
# If it hangs or errors, the server isn't running correctly.

Reference: Ollama Linux Installation Guide

4. Preparing the AI Models

Make the required AI model files available on the server. Choose a suitable location, perhaps a models/ subdirectory within your project or a central /opt/ai-models/ directory.

Uploading/Downloading Models

From Hugging Face: Use huggingface-cli (install with pip install huggingface_hub):

  huggingface-cli download repo_id path/to/model.gguf --local-dir /path/on/server/models --local-dir-use-symlinks False
  # Replace repo_id, model filename, and /path/on/server/models

From Local Machine: Use scp (Secure Copy) to upload models from your development machine. Replace placeholders.

  # Upload a single model file
  scp /path/on/local/model.gguf your_server_username@your_server_hostname_or_ip:/path/on/server/models/

  # Upload an Ollama Modelfile
  scp /path/on/local/Modelfile your_server_username@your_server_hostname_or_ip:/path/on/server/models/

  # Upload an entire directory recursively
  scp -r /path/on/local/model_directory your_server_username@your_server_hostname_or_ip:/path/on/server/models/

GGUF Merging: If a model is split (e.g., model-part-1.gguf, model-part-2.gguf), you might need llama.cpp tools to merge them. Clone llama.cpp, build it, and use llama-gguf-split:

  # Assuming llama.cpp tools are built and in PATH
  # llama-gguf-split --merge input_part_*.gguf output_merged.gguf

Building Models with Ollama

To integrate local model files (like .gguf) with Ollama or define custom model parameters, use a Modelfile. Create this text file (e.g., MyModelModelfile) in the same directory as the base model file (.gguf) on the server.

Example Modelfile content:

# Use FROM with a relative path to the model file in the same directory
FROM ./local_model_filename.gguf

# (Optional) Define a prompt template
TEMPLATE """[INST] {{ .Prompt }} [/INST]"""

# (Optional) Set parameters
PARAMETER temperature 0.7
PARAMETER top_k 40
# Add other parameters as needed (stop sequences, etc.)

Build and register the model with Ollama using a chosen name:

# Ensure Ollama server is running
# Navigate to the directory containing the Modelfile and the .gguf file
cd /path/on/server/models/

# Create the model - use a descriptive name
ollama create your_custom_model_name -f MyModelModelfile

Verify the model is available: ollama list.

5. Setting Up Environment Variables

Applications often require configuration like API keys or database URLs, best managed via environment variables. A common method is using a .env file in the project's root directory. Never commit your .env file to Git. Add .env to your .gitignore file.

Create a file named .env in your project root (/path/to/your/project/.env) with content like this (replace placeholder values):

# Example .env file content
# Framework secret key (generate a strong random key)
SECRET_KEY=your_strong_random_secret_key

# API keys for external services
EXTERNAL_API_KEY=your_external_api_key_value

# Ollama configuration if your app needs to explicitly connect
OLLAMA_HOST=http://127.0.0.1:11434

# Other configuration variables
DATABASE_URL=your_database_connection_string

Your Python application code needs to load these variables, often using a library like python-dotenv (pip install python-dotenv).

6. Running the Project Manually (Testing)

Before setting up the service, run the application manually from the terminal to ensure it starts and functions correctly.

Ensure Ollama is Running: Use ollama list or systemctl status ollama (if installed as a service) to verify.
Activate Environment (if using venv): source /path/to/your/project/venv/bin/activate

Start Application: Navigate to the project root directory. Use a ASGI server like uvicorn for FastAPI. Replace placeholders.

cd /path/to/your/project

# Example command using uvicorn
# assumes your FastAPI app instance is named 'app' in 'main.py'
# use the port your app is configured to listen on
uvicorn main:app --host 0.0.0.0 --port <your_app_port> --reload

- `--host 0.0.0.0`: Makes the app accessible from other machines on the network (ensure firewall rules permit traffic on `<your_app_port>`).
- `--port <your_app_port>`: The port the application will listen on (e.g., 8000).
- `--reload`: **Use only for testing.** Enables auto-reloading on code changes. **Remove this flag for production deployment.**

Test:
- API Endpoints: Use tools like curl, Postman, or Insomnia to send requests (e.g., curl http://your_server_hostname_or_ip:<your_app_port>/api/some_endpoint).
- Web UI: Access any web interface via a browser at http://your_server_hostname_or_ip:<your_app_port>.
- Logs: Check the terminal output for errors.

Deploying as a Service with `systemd`

Running applications manually in the terminal isn't suitable for production. systemd is the standard Linux service manager used to:

Start the application automatically on server boot.
Restart the application automatically if it crashes.
Manage the application as a background process with proper logging.

Creating the Service File

Create a service definition file using a text editor with sudo privileges. Use a descriptive name (e.g., your-app-name.service).

sudo nano /etc/systemd/system/your-app-name.service

Paste the following template into the file. Carefully read the comments and replace ALL placeholders.

[Unit]
Description=My Python AI Application Service # A descriptive name for your service
After=network.target
# If your app strictly requires Ollama to be running first (and Ollama is a systemd service), uncomment:
# Wants=ollama.service
# After=network.target ollama.service

[Service]
# !!! SECURITY BEST PRACTICE: DO NOT RUN AS ROOT !!!
# Create a dedicated, non-root user for your application.
# Replace 'your_app_user' with the actual username. Ensure this user has permissions
# to read project files and write to necessary directories (e.g., logs, uploads).
User=your_app_user
# Group=your_app_group # Often the same as the user, uncomment if needed

# Set the working directory to your project's root absolute path
WorkingDirectory=/path/to/your/project # !!! REPLACE THIS ABSOLUTE PATH !!!

# Command to start the application. Use the ABSOLUTE PATH to the executable (uvicorn, gunicorn, etc.).
# Find the path: 'which uvicorn' (as your_app_user, possibly after activating venv)
# Or it might be like: /path/to/your/project/venv/bin/uvicorn OR /home/your_app_user/.local/bin/uvicorn
# Adjust 'main:app', host, port, and other args. REMOVE --reload!
ExecStart=/path/to/executable/uvicorn main:app --host 0.0.0.0 --port <your_app_port> --forwarded-allow-ips='*' # !!! REPLACE PATH, APP, PORT & CHECK ARGS !!!

# Restart policy
Restart=always
RestartSec=5 # Wait 5 seconds before restarting

# Logging: Redirect stdout/stderr to systemd journal
StandardOutput=journal
StandardError=journal

# Optional: Load environment variables from the .env file
# Ensure the path is absolute. Permissions must allow 'your_app_user' to read it.
# EnvironmentFile=/path/to/your/project/.env # !!! REPLACE THIS ABSOLUTE PATH !!!
# Note: Variables here might override system-wide or user-specific environment settings.

[Install]
WantedBy=multi-user.target # Start the service during normal system boot

Crucial Placeholders and Settings to Verify:

Description: A clear name.
User/Group: Must be changed to a dedicated, non-root user (your_app_user). Ensure file/directory permissions are correct for this user.
WorkingDirectory: The absolute path to your project's root.
ExecStart:
- The absolute path to the uvicorn (or other WSGI/ASGI server) executable. If using a virtual environment, it's typically inside venv/bin/.
- main:app must match your Python file and FastAPI/Flask app instance.
- <your_app_port>, --host, and other arguments must be correct for production. Remove --reload.
- --forwarded-allow-ips='*' may be needed if behind a reverse proxy (like Nginx or Apache). Adjust as needed for security.
(Optional) EnvironmentFile: If used, the absolute path to your .env file.

Save the file and exit the editor (Ctrl+X, then Y, then Enter in nano).

Enabling and Starting the Service

Manage the new service using systemctl:

Reload systemd configuration: To make it aware of the new file.
```
sudo systemctl daemon-reload
```
Enable the service: To make it start automatically on boot. Use the same filename you created.
```
sudo systemctl enable your-app-name.service
```

Start the service: To run it immediately.

sudo systemctl start your-app-name.service

Check the status: To verify it's running.
```
sudo systemctl status your-app-name.service
```
Look for active (running). If it says failed or isn't active, check the logs.
View logs: To see application output and troubleshoot errors.
```
sudo journalctl -u your-app-name.service -f
```

- `-u your-app-name.service`: Filters logs for your specific service.
- `-f`: Follow the logs in real-time (like `tail -f`). Press `Ctrl+C` to stop following.
- To see older logs, remove `-f`: `sudo journalctl -u your-app-name.service --since "1 hour ago"`

Your AI application should now be running as a managed background service.

Frequently Encountered Issues (FAQ)

Common problems during setup or runtime.

Environment Configuration Issues

Slow SSH Connection/Typing:
- Cause: High network latency.
- Solution: Enable SSH compression with the -C flag:
```
ssh -C your_server_username@your_server_hostname_or_ip ...
```

Runtime Issues

Missing Environment Variables: Errors like KeyError: 'SECRET_KEY' or ValueError: Required setting X not found.
- Cause: The application needs environment variables that aren't defined in its running context.
- Solution: Ensure required variables are set either:
- In the .env file, and the application uses python-dotenv to load it.
- Or listed in the systemd service file using the Environment="VAR_NAME=value" directive (less common for many variables) or the EnvironmentFile= directive pointing to your .env file. Verify the systemd service user has permission to read the EnvironmentFile. Reload (daemon-reload) and restart the service after changes.
Ollama Runtime Error: Error: llama runner process has terminated: exit status X.
- Cause: Varies. Could be Ollama bugs, insufficient RAM/VRAM for the model, model file corruption, or incompatibility.
- Solution:
- Check Ollama's logs: journalctl -u ollama.service (if running as systemd service).
- Search the Ollama GitHub Issues for the specific error message or exit status.
- Ensure the server meets the resource requirements for the model.
- Try a different (perhaps smaller) model to isolate the issue.
- Consider trying a different Ollama version (downgrade or upgrade), checking compatibility notes.
Ollama Slow/No Response/Long Inference Time:
- Cause 1: Network proxies interfering. Solution 1: If you are running Ollama manually or configuring its environment, try unsetting proxy variables: unset http_proxy https_proxy NO_PROXY. For the system service, proxies might need to be configured/disabled system-wide or within the service's environment settings.
- Cause 2: Insufficient hardware resources (CPU, RAM, VRAM if using GPU).
- Solution 2: Verify model requirements vs. server specs. Monitor resource usage (htop, nvidia-smi if GPU). Use smaller models or upgrade hardware if needed.
ollama serve Fails: Port Already in Use: Error like listen tcp 127.0.0.1:11434: bind: address already in use.
- Cause: Another process (likely another Ollama instance or your app if misconfigured) is using port 11434.
- Solution: Stop the conflicting process.
- If Ollama is a service: sudo systemctl stop ollama.
- Find and kill manually:
```
sudo lsof -i :11434 # Find the PID using the port
sudo kill <PID>      # Replace <PID> with the process ID found
# Or more forcefully (use with caution):
# sudo pkill ollama
# sudo killall ollama
```
- After stopping the conflict, try starting your service/Ollama again.

Conclusion

Deploying a Python AI application involves careful environment setup, dependency management, model handling, and robust process management. A solid foundation is provided by tools like uv for speed, Ollama for local model serving, FastAPI for the API, and system for reliable service operation. Remember to prioritize security by using non-root users and managing secrets appropriately through environment variables. By following these steps and adapting them to your specific project needs, you can successfully deploy your application for continuous operation.

Semantic HTML

Mitchell — Sat, 19 Apr 2025 16:19:39 +0000

Semantic HTML

In the context of computer science, semantics refers to the meaning of programming languages.

In the context of frontend development, semantics can be seen in HTML, CSS, and JavaScript.

In terms of HTML, the tags themselves have semantic meaning, for example:

<ul> for unordered list
<ol> for ordered list
<table> for table or tabular etc...

Semantic Elements

HTML5 introduced semantic elements:

`<article>`

A self-contained composition in a doc, page, app, or site, which is intended to be independently distributable or reusable.

Example

A blog post, a magazine, an article, a product card, a user-submitted comment, a widget, or a gadget.

Usage

typically including a heading: <h1> - <h6> as the child
when multiple <article> nested, the inner one should be related to the outer one.
put author info of <article> in <address>
publication data and time of an <article> can be using <time>'s datetime attribute.

`<aside>`

A portion of a document whose content is indirectly related to the main content.

Example

A sidebar or call-out box.

Usage

Do not use it to tag parenthesized text.

`<details>`, `<summary>`

<details> creates a disclosure widget in which the info is visible only when the widget is toggled into an open state.

Use <summary> or label for <summary>. The default state is closed and only shows the summary.

Example

LLM's thinking widget.

Usage

<summary> may only be used as the first child of a <details> element.

Attribute

open: Boolean value to indicate the content visibility.
name: group multiple <details> with the same name, but only one can be visible.

Event

toggle: detect when the widget changes state

`<figure>`, `<figcaption>`

<figure> for self-contained content, potentially with a caption <figcaption>.

Example

Images, illustrations, diagrams, code snippets.

`<header>`, `<footer>`

<footer> represents a footer for its nearest ancestor section content or sectioning root element. <header> represents introductory content.

Example

<footer> for author info, related link, or copyright.
<header> may contain heading elements, a search form, an author name, a logo, etc.

Usage

<footer> can be the footer of the whole page when its sectioning root is <body>
If <address> is used for author info, it could be placed in <footer>
When <header>'s context is <body>, it has an identical meaning to the site-wide banner. It's a banner in the accessibility tree. Or it's a section in the accessibility tree, which contains headings.

`<form>`

<form> provides interactive controls for submitting information.

Attributes

autocomplete: whether input elements can, by default, have the values automatically completed by the browser.
name: name of the form, it must be unique among the forms and not the empty string

For submission:

action: the URL that processes the info.
method: the HTTP method to submit the form with, allowed methods: post, get, dialog.
target: indicates where to display the response after submitting the form, example: _self(default), _blank(new browsing context), _parent(parent context)
novalidate: boolean indicates that the form shouldn't be validated.

`<main>`

The dominant content of the <body> of a document. The content within <main> should be directly related to the central topic of a document.

A document can't have one more <main> without a hidden attribute.

Usage

<main> doesn't contribute to the document's outline, it doesn't affect the DOM's concept of the structure of the page.
The content within <main> should be unique, and the repeated content should be placed outside of <main>

`<mark>`

Represents text which is marked or highlighted for reference or notation purposes due to the marked passage's relevance in the enclosing context.

Usage

Used in <q> or <blockquote>
Otherwise, it indicates a portion of the document's content is relevant to the user's current activity.
Don't use it for syntax highlight, use <span> with CSS instead; don't confuse it with <strong>, the former denotes content has a degree of relevance, the latter denotes text of importance.

`<nav>`

Provide navigation links.

Examples

menus
table of contents(toc)
indexes

Usage

For a major block of navigation links, not for all the links
A doc can have several <nav> elements

`<section>`

Represents a generic standalone section of a document; should always have a heading.

Usage

Only be used if there are no more specific elements to represent it.
There are better choices:
- represents the main content? Use <main>
- represents tangential info? Use <aside>
- represents an atomic unit of content related to the main flow? Use <article>
- used for styling wrapper, use <div>

`<time>`

Attribute

datetime

Usage

Presenting dates and times in a machine-readable format.
Don't use it for dates prior to the introduction of the Gregorian calendar

Semantic Attributes

`role`

The role attribute describes the role an element has in the context of the document. It is a global attribute, meaning it's valid for every element, defined by the ARIA spec.

It helps build the AOM(Accessibility Object Model).

Why semantics?

The benefits of writing semantic markup are as follows:

Better SEO: A web app built with semantics would be considered important by a search engine.
Better A11y:
- Screen readers can use it easily than without semantics.
- Semantic tags like <header>, <nav>, <main>, <footer> can create semantic landmarks which provide structure to web content and ensure important sections of content are keyboard-navigable for screen reader users.
Better Readability:
- Developers can use search to quickly find targeted elements
- Avoid a large number of <div>s

Content categories

When writing the semantic elements, it's beneficial to keep content categories in mind. It helps to define the content model of elements.
You can check it at Content categories - MDN.

Basically, there are 7 types:

Metadata content: modify the presentation or the behavior of the rest of the doc, set up links to other docs, convey out-of-band info.
- Examples:
- <base>
- everything in <head>: <link>, <meta>, <script>, <style>, <title>
Flow content: most elements inside the <body>
- Examples:
- heading elements, sectioning elements, phrasing elements, embedding elements, interactive elements, and form-related elements.
Sectioning content: a subset of flow content, creates a section in the current outline defining the scope of <header> and <footer> elements.
- Examples:
- <article>, <aside>, <nav>, <section>
Heading content: a subset of flow content, defines the title of a section.
- Examples:
- <h1> - <h6>
- <hgroup>
Phrasing content: a subset of flow content, text, and markup within a document.
Embedded content: a subset of flow content, imports another resource or inserts content from another markup language or namespace into the document.
- Examples:
- <audio>, <video>, <iframe>, <svg>, <img>, <embed>, <canvas>, <picture>
Interactive content: a subset of flow content, designed for user interaction.
- Examples:
- <button>, <label>, <details>, <select>, <textarea>

Tools

You can use the validator to validate your HTML code.
You can switch to Accessibility Tree View in Chrome DevTools Element panel.

Reference

Text compression & Code splitting & Modern image formats - Performance optimization

Mitchell — Mon, 09 Dec 2024 14:17:48 +0000

I tried the following to optimize my side project performance:

text compression
code splitting
modern image formats.

Profiler

The app I built used Vite with pnpm. Modern web build tools automatically optimize web performance by default in the build process. So we can pnpm run build then pnpm dlx serve dist. Then use Lighthouse of Chrome DevTools as a guide to address each bottleneck it lists.

Enable text compression

It affects FCP and LCP.

The first thing that Lighthouse suggests is compressing text using algorithms like br or gzip.

The common practice is to add Accept-Encoding: gzip whenever making web requests. Since the app I am building serves the resource locally, I installed the vite-plugin-compress to compress the files.

Step 1: install vite-plugin-compress
Step 2: configure the vite.config.js file, and add the plugin and some parameters. As Google Developers suggests, it should use br(brotliCompress) over gzip as much as possible.

For example

viteCompression({
      verbose: true,
      disable: false,
      algorithm: 'brotliCompress',
      ext: '.br',
    }),

Step 3: run pnpm run build to compress

It successfully compressed .js and .css files.

Logs:

✨ [vite-plugin-compression]:algorithm=brotliCompress - compressed file successfully.

Vite would compress the file by default using .gzip, but brotliCompress can do better, compression during the build process:

Vite with gzip

vite v5.4.10 building for production...
✓ 654 modules transformed.

index-B9QUW17e.css 8.60 kB │ gzip: 2.33 kB
PauseMenu-DjZ95K-6.js 1.77 kB │ gzip: 0.62 kB
index-ohAKp9W9.js 1,688.05 kB │ gzip: 454.20 kB

Vite-plugin-compression with br

✨ [vite-plugin-compression]:algorithm=brotliCompress - compressed file successfully:
PauseMenu-DjZ95K-6.js.br 1.73kb / brotliCompress: 0.51kb
index-B9QUW17e.css.br 8.40kb / brotliCompress: 1.97kb
index-ohAKp9W9.js.br 1648.49kb / brotliCompress: 345.30kb

Reducing unused JavaScript

It affects FCP and LCP.

Use the Coverage Tab in Google DevTools to see the scripts that have unused bytes over 20kbs.

Since I am using Vite with React, code splitting is the first thing about reducing unused JavaScript.

In React, <Suspense> and lazy() can help with that.

Use <Suspense> to wrap the whole App and provide a fallback UI, like <div>Loading</div>, this provides a fallback UI when the app is loading.
Use lazy() to wrap the components which not used on the initial page. For example, for games, when users press down the Esc key, a menu that you can wrap up pops up.

Serve images with modern formats

Chrome Developers suggests serving images in AVIF or WebP format. I chose WebP because it has more support across browsers.

The latest versions of Chrome, Firefox, Safari, Edge, and Opera support WebP, while AVIF support is more limited.

You can check WebP image format support info at Can I use.

You can install the cwebp library at WebP and use the command cwebp -q 50 images/flower1.jpg -o images/flower1.webp to convert .png to .webp.

This command converts, at a quality of 50 (0 is the worst; 100 is the best), the images/flower1.jpg file and saves it as images/flower1.webp.

The compression result is quite impressive. One of the files is reduced in size from 3.5 MB to 178kb. Even the low information intensity ones give 4x compression.

We can even write a simple .bat script to automatically convert all the .png images under the target folder into .webp images.

@echo off
setlocal enabledelayedexpansion

:: Set the path to the cwebp executable
set CWEBP_PATH=

:: Set the target folder path
set TARGET_FOLDER=

:: Set the quality (0-100, where 100 is lossless)
set QUALITY=50

:: Loop through all PNG files in the target folder
for %%F in ("%TARGET_FOLDER%\*.png") do (
    :: Get the file name without extension
    set "filename=%%~nF"

    :: Convert PNG to WebP
    "%CWEBP_PATH%" -q %QUALITY% "%%F" -o "%TARGET_FOLDER%\!filename!.webp"

    if !errorlevel! equ 0 (
        echo Converted: %%F to !filename!.webp
    ) else (
        echo Failed to convert: %%F
    )
)

echo Conversion complete.
pause

Reference

Notes on GPU-Mode lecture 1

Mitchell — Thu, 14 Nov 2024 08:26:05 +0000

Profiler

Computer performance is about time and memory trade-offs. Since calculating devices are way more expensive, most of the time, time is the priority to care about.

Why use a profiler?

CUDA is async so can't use the Python time module
Profilers are way more powerful

Tools

There are three profilers:

autograd profiler: numerical
Pytorch profiler: visual
NVIDIA Nsight Compute

Autograd profiler utilizes torch.cuda.Event() to measure performance.

PyTorch profiler utilizes the method profile() from the Profiler context manager torch.profiler to analyze performance.
You can export the result as a .json file and upload it to chrome://tracing/ to visualize it.

Demo

The course provides a simple program to show how to use autograd profiler to analyze the performance of three ways to do square operations:

by torch.square()
by ** operator
by * operator

def time_pytorch_function(func, input):
    # CUDA IS ASYNC so can't use python time module
    start = torch.cuda.Event(enable_timing=True)
    end = torch.cuda.Event(enable_timing=True)

    # Warmup
    for _ in range(5):
        func(input)

    start.record()
    func(input)
    end.record()
    torch.cuda.synchronize()
    return start.elapsed_time(end)

time_pytorch_function(torch.square, b)
time_pytorch_function(square_2, b)
time_pytorch_function(square_3, b)

The result below is done on the NVIDIA T4 GPU.

Profiling torch.square:
Self CPU time total: 10.577ms
Self CUDA time total: 3.266ms

Profiling a * a:
Self CPU time total: 5.417ms
Self CUDA time total: 3.276ms

Profiling a ** 2:
Self CPU time total: 6.183ms
Self CUDA time total: 3.274ms

It turns out:

CUDA operation is faster than CPU.
The * operator is doing an aten::multiply operation rather than an aten::pow, and the former is faster. It is probably because that multiply is used more than pow and many developers spend time on optimizing it.
The performance difference on CUDA is minimal. torch.square is the slowest operation considering the CPU time
aten::square is a call to aten::pow
All three methods launched a cuda kernel called native::vectorized_elementwise_kernel<4, at...

Integrating CUDA kernels in PyTorch

There are a couple of ways to do that:

use load_inline from torch.utils.cpp_extendsion
use Numba which is a compiler that compiles a decorated Python function into the machine code that runs on both CPU and GPU
use Triton

We can use load_inline from torch.utils.cpp_extendsion to load the CUDA kernel as a PyTorch extension by load_inline(name, cpp_sources, cuda_sources, functions, with_cuda, build_directory).

from torch.utils.cpp_extension import load_inline

square_matrix_extension = load_inline(
    name='square_matrix_extension',
    cpp_sources=cpp_source,
    cuda_sources=cuda_source,
    functions=['square_matrix'],
    with_cuda=True,
    extra_cuda_cflags=["-O2"],
    build_directory='./load_inline_cuda',
    # extra_cuda_cflags=['--expt-relaxed-constexpr']
)

a = torch.tensor([[1., 2., 3.], [4., 5., 6.]], device='cuda')
print(square_matrix_extension.square_matrix(a))

Hands-on

Use autograd profiler on `mean` operation

When using autograd profiler, remember:

Warmup the GPU before recording so that the GPU enters a steady state
Average multiple runs for more reliable results

import torch

# Method 1: use `torch.mean()`
def mean_all_by_torch(input_tensor):
    return torch.mean(input_tensor)

# Method 2: use `mean()` of the tensor
def mean_all_by_tensor(input_tensor):
    return input_tensor.mean()

# Method 3: use `torch.sum()` and `tensor.numel()`
def mean_all_by_combination(input_tensor):
    return torch.sum(input_tensor) / input_tensor.numel()

def time_pytorch_function(func, input_tensor, warmup=5, runs=100):
    # Warmup
    for _ in range(warmup):
      func(input_tensor)

    times = []
    start = torch.cuda.Event(enable_timing=True)
    end = torch.cuda.Event(enable_timing=True)

    for _ in range(runs):
        start.record()
        func(input_tensor)
        end.record()
        torch.cuda.synchronize()
        times.append(start.elapsed_time(end))

    return sum(times) / len(times)

input_tensor = torch.randn(10000, 10000).cuda()

print("torch.mean() time:", time_pytorch_function(mean_all_by_torch, input_tensor))
print("tensor.mean() time:", time_pytorch_function(mean_all_by_tensor, input_tensor))
print("manual mean time:", time_pytorch_function(mean_all_by_combination, input_tensor))


with torch.profiler.profile() as prof:
    mean_all_by_torch(input_tensor)
print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=10))

with torch.profiler.profile() as prof:
    mean_all_by_tensor(input_tensor)
print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=10))

with torch.profiler.profile() as prof:
    mean_all_by_combination(input_tensor)
print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=10))

Use Pytorch profiler on `mean` operation

import torch
from torch.profiler import profile, ProfilerActivity

with profile(activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA]) as prof:
    for _ in range(10):
        mean_tensor = torch.mean(torch.randn(10000, 10000).cuda())

prof.export_chrome_trace("mean_trace.json")

Implementing triton code for `torch.mean()`

import triton
import triton.language as tl
import torch

@triton.jit
def mean_kernel(
    x_ptr,          # pointer to input tensor
    output_ptr,     # pointer to output tensor
    n_elements,     # total number of elements
    BLOCK_SIZE: tl.constexpr,  # number of elements per block
):

    pid = tl.program_id(0)

    block_start = pid * BLOCK_SIZE
    block_end = tl.minimum(block_start + BLOCK_SIZE, n_elements)

    acc = 0.0

    for idx in range(block_start, block_end):
        x = tl.load(x_ptr + idx)
        acc += x


    block_mean = acc / n_elements

    # Store result
    tl.store(output_ptr + pid, block_mean)

# Wrapper function
def triton_mean(x: torch.Tensor) -> torch.Tensor:

    x = x.contiguous().view(-1)
    n_elements = x.numel()


    BLOCK_SIZE = 1024
    grid = (triton.cdiv(n_elements, BLOCK_SIZE),)


    output = torch.empty(grid[0], device=x.device, dtype=x.dtype)


    mean_kernel[grid](
        x_ptr=x,
        output_ptr=output,
        n_elements=n_elements,
        BLOCK_SIZE=BLOCK_SIZE,
    )

    return output.sum()

# Example usage:
if __name__ == "__main__":
    # Create test tensor
    x = torch.randn(1000000, device='cuda')

    # Compare results
    torch_mean = torch.mean(x)
    triton_mean_result = triton_mean(x)

    print(f"PyTorch mean: {torch_mean}")
    print(f"Triton mean: {triton_mean_result}")
    print(f"Difference: {abs(torch_mean - triton_mean_result)}")

Reference

Web APIs - Custom Hooks

Mitchell — Tue, 12 Nov 2024 01:29:59 +0000

You can find all the code in this post on the repo Github.

Web APIs-related React custom hooks challenges

`useLocalStorage()`

import { useState, useEffect } from "react";

function useLocalStorage(key, initialValue) {
  const [storedValue, setStoredValue] = useState(() => {
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
    } catch (err) {
      console.error(`Error reading localStorage key "${key}":`, error);
      return initialValue;
    }
  });

  useEffect(() => {
    try {
      window.localStorage.setItem(key, JSON.stringify(storedValue));
    } catch (err) {
      console.error(`Error writing localStorage key “${key}”:`, error);
    }
  }, [key, storedValue]);

  const setValue = (value) => {
    try {
      const valueToStore =
        value instanceof Function ? value(storedValue) : value;
      setStoredValue(valueToStore);
    } catch (err) {
      console.error(`Error setting localStorage key “${key}”:`, error);
    }
  };

  const removeValue = () => {
    try {
      window.localStorage.removeItem(key);
      setStoredValue(initialValue);
    } catch (error) {
      console.error(`Error removing localStorage key “${key}”:`, error);
    }
  };

  return [storedValue, setValue, removeValue];
}

function LocalStorageExample() {
  const [name, setName, removeName] = useLocalStorage("name", "John Doe");

  return (
    <div>
      <h2>Local Storage Example</h2>
      <p>Stored Name: {name}</p>
      <input
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
        placeholder="Enter your name"
      />
      <button onClick={removeName}>Remove Name</button>
    </div>
  );
}

export default function App() {
  return (
    <div>
      <h1>Using useLocalStorage Hook</h1>
      <LocalStorageExample />
    </div>
  );
}

Timer - Custom Hooks

Mitchell — Sun, 10 Nov 2024 01:44:26 +0000

You can find all the code in this post on the repo Github.

Timer-related React custom hooks challenges

`useCountdown()`

import { useEffect, useRef, useState } from "react";

function useCountdown(initialValue) {
  const [count, setCount] = useState(initialValue);
  const [isActive, setIsActive] = useState(false);
  const intervalRef = useRef(null);

  function start() {
    setIsActive(true);
  }

  function pause() {
    setIsActive(false);
    clearInterval(intervalRef.current);
  }

  function reset() {
    setCount(initialValue);
    setIsActive(false);
    clearInterval(intervalRef.current);
  }

  useEffect(() => {
    if (isActive && count > 0) {
      intervalRef.current = setInterval(() => {
        setCount((prevCount) => prevCount - 1);
      }, 1000);
    } else if (count === 0) {
      clearInterval(intervalRef.current);
    }

    return () => clearInterval(intervalRef.current);
  }, [count, isActive]);

  return { count, isActive, start, pause, reset };
}

export default function App() {
  const { count, isActive, start, pause, reset } = useCountdown(10);

  return (
    <div>
      <h1>Countdown: {count}</h1>
      <button onClick={start} disabled={isActive}>
        Start
      </button>
      <button onClick={pause} disabled={!isActive}>
        Pause
      </button>
      <button onClick={reset}>Reset</button>
      {count === 0 && <p>Time's up!</p>}
    </div>
  );
}

`useDebounce()`

import { useState, useEffect } from "react";

function useDebounce(value, delay) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timerId = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    return () => clearTimeout(timerId);
  }, [value, delay]);

  return debouncedValue;
}

/* Usage example */

export default function App() {
  const value = useDebounce(2, 2000);

  return (
    <div>
      <p>Value: {value}</p>
    </div>
  );
}

`useInterval()`

import { useEffect, useRef, useState } from "react";

function useInterval(callbackFn, delay) {
  const callbackFnRef = useRef(callbackFn);

  useEffect(() => {
    callbackFnRef.current = callbackFn;
  }, [callbackFn]);

  useEffect(() => {
    const timerId = setInterval(() => {
      callbackFnRef.current();
    }, delay);

    return () => clearInterval(timerId);
  }, [delay]);
}

/* Usage example */

export default function App() {
  const [count, setCount] = useState(0);

  useInterval(() => {
    setCount((prev) => prev + 1);
  }, 1000);

  return <div>Count: {count}</div>;
}

`useThrottle()`

import { useRef, useCallback, useState } from "react";

function useThrottle(callback, delay) {
  const lastCall = useRef(0);
  const timerId = useRef(null);

  const throttledFunction = useCallback((...args) => {
    const now = Date.now();

    if (lastCall.current === 0 || now - lastCall.current >= delay) {
      lastCall.current = now;
      callback(...args);
    } else if (!timerId.current) {
      timerId.current = setTimeout(() => {
        lastCall.current = Date.now();
        callback(...args);
        timerId.current = null;
      }, delay - (now - lastCall.current));
    }
  }, [callback, delay]);

  return throttledFunction;
}

export default function App() {
  const [count, setCount] = useState(0);

  const handleScroll = () => {
    setCount((prevCount) => prevCount + 1);
    console.log("Scroll event triggered", count);
  };

  const throttledScroll = useThrottle(handleScroll, 1000); // Throttle to 1 second

  return (
    <div
      onScroll={throttledScroll}
      style={{ height: "200vh", padding: "20px" }}
    >
      <h2>Scroll down to see throttling in action!</h2>
      <p>Scroll Count: {count}</p>
    </div>
  );
}

`useTimeout()`

import { useEffect, useRef, useState } from 'react';

function useTimeout(callbackFn, delay) {
  const callbackFnRef = useRef(callbackFn);

  useEffect(() => {
    callbackFnRef.current = callbackFn;
  }, [callbackFn]);

  useEffect(() => {
    const timerId = setTimeout(() => {
      callbackFnRef.current();
    }, delay);

    return () => clearTimeout(timerId);
  }, [delay]);
}

/* Usage example */

export default function App() {
  const [count, setCount] = useState(0);

  useTimeout(() => {
    setCount((prev) => prev + 1);
  }, 1000);

  return <div>Count: {count}</div>;
}

Reference

8. useDebounce() - BFE.dev

Request - Custom Hooks

Mitchell — Sat, 09 Nov 2024 05:42:54 +0000

You can find all the code in this post on the repo Github.

Request-related React custom hooks challenges

`useSWR()`

import { useState, useEffect } from "react";

function useSWR(_key, fetcher) {
  const [data, setData] = useState();
  const [error, setError] = useState();
  const fetchResult = fetcher();

  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await fetchResult;
        setData(response);
      } catch (err) {
        setError(err);
      }
    };

    if (fetchResult instanceof Promise) {
      fetchData();
    }
  }, []);

  const result = fetchResult instanceof Promise ? data : fetchResult;

  return {
    data: result,
    error,
  };
}

/* Usage example */

export default function App() {
  return <div></div>;
}

`useFetch()`

import { useState, useEffect } from "react";

function useFetch(url) {
  const [data, setData] = useState();
  const [error, setError] = useState();
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await fetch(url);
        if (!response.ok) {
          throw new Error(`HTTP error: ${response.status}`);
        }
        const result = await response.json();
        setData(result);
      } catch (err) {
        setError(err.message);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, [url]);

  return { data, error, loading };
}

/* Usage example */

export default function App() {
  const { data, error } = useFetch("https://randomuser.me/api/");

  return (
    <div>
      <p>Fetch result: {JSON.stringify(data) ?? error}</p>
    </div>
  );
}

Reference

4. useSWR() I - BFE.dev

React lifecycles - Custom Hooks

Mitchell — Fri, 08 Nov 2024 13:08:38 +0000

You can find all the code in this post on the repo Github.

Lifecycle-related React custom hooks challenges

`useEffectOnce()`

import { useEffect, useState } from "react";

function useEffectOnce(effect) {
  useEffect(() => {
    return effect();
  }, []);
}

/* Usage example */

export default function App() {
  const [value, setValue] = useState();

  useEffectOnce(() => {
    setValue("once!");
  });

  return (
    <div>
      <p>value: {value}</p>
    </div>
  );
}

`useIsFirstRender()`

import { useEffect, useState } from "react";

function useEffectOnce(effect) {
  useEffect(() => {
    return effect();
  }, []);
}

/* Usage example */

export default function App() {
  const [value, setValue] = useState();

  useEffectOnce(() => {
    setValue("once!");
  });

  return (
    <div>
      <p>value: {value}</p>
    </div>
  );
}

`useIsMounted()`

import { useEffect, useRef } from "react";

function useIsMounted() {
  const isMountedRef = useRef(true);

  useEffect(() => {
    return () => {
      isMountedRef.current = false;
    };
  }, []);

  return () => isMountedRef.current;
}

/* Usage example */

export default function App() {
  const isFirstMount = useIsMounted();

  return (
    <div>
      <p>Is first mount: {String(isFirstMount())}</p>
    </div>
  );
}

`usePrevious()`

import { useRef, useEffect } from "react";

function usePrevious(value) {
  const previousRef = useRef();

  useEffect(() => {
    previousRef.current = value;
  }, [value]);

  return previousRef.current;
}

/* Usage example */

export default function App() {
  const previousValue = usePrevious(1);

  return (
    <div>
      <p>Previous value: {previousValue}</p>
    </div>
  );
}

`useUpdate()`

import { useReducer } from "react";

const updateReducer = (num) => (num + 1) % 1_000_000;

function useUpdate() {
  const [_, update] = useReducer(updateReducer, 0);

  return update;
}

export default function App() {
  return <div></div>;
}

`useUpdateEffect()`

import { useRef, useEffect } from "react";

function useUpdateEffect(effect, deps) {
  const isFirstRenderRef = useRef(true);

  useEffect(() => {
    if (isFirstRenderRef.current) {
      isFirstRenderRef.current = false;
      return;
    }

    return effect();
  }, deps);
}

export default function App() {
  const fetchData = () => {};

  const effect = useUpdateEffect(fetchData);
  return (
    <div>
      <p></p>
    </div>
  );
}

Reference

Event - Custom Hooks

Mitchell — Thu, 07 Nov 2024 06:05:41 +0000

You can find all the code in this post at the repo Github.

Event-related React custom hooks challenges

`useBodyScrollLock()`

import { useLayoutEffect, useState } from "react";

function useBodyScrollLock() {
  useLayoutEffect(() => {
    const originalStyle = window.getComputedStyle(document.body).overflow;

    document.body.style.overflow = "hidden";

    return () => {
      document.body.style.overflow = originalStyle;
    };
  }, []);
}

function Modal({ onClose }) {
  useBodyScrollLock();

  return (
    <div
      style={{
        zIndex: 100,
        background: "rgba(0,0,0,0.5)",
        display: "flex",
        justifyContent: "center",
        alignItems: "center",
        height: "100vh",
      }}
    >
      <div style={{ padding: 20, background: "#fff", borderRadius: 8 }}>
        <h2>Modal Content</h2>
        <button onClick={onClose}>Close</button>
      </div>
    </div>
  );
}

export default function App() {
  const [modalOpen, setModalOpen] = useState(false);

  return (
    <div style={{ height: "200vh", textAlign: "center", paddingTop: 100 }}>
      <button onClick={() => setModalOpen(true)}>Open Modal</button>
      {modalOpen && <Modal onClose={() => setModalOpen(false)} />}
    </div>
  );
}

`useClickOutside()`

import { useRef, useEffect } from "react";

function useClickOutside(callbackFn) {
  const ref = useRef(null);

  useEffect(() => {
    const click = ({ target }) => {
      if (target && ref.current && !ref.current.contains(target)) {
        callbackFn();
      }
    };

    document.addEventListener("mousedown", click);

    return () => {
      document.removeEventListener("mousedown", click);
    };
  }, []);

  return ref;
}

/* Usage example */

export default function App() {
  const ref = useClickOutside();

  return <button>ClickOutside: {String(ref.current)}</button>;
}

`useEventListener()`

import { useEffect, useState } from "react";

function useEventListener(eventName, handler, element = window) {
  useEffect(() => {
    const isSupported = element && element.addEventListener;

    if (!isSupported) {
      return;
    }

    const eventListener = (event) => {
      handler(event);
    };

    element.addEventListener(eventName, eventListener);

    return () => {
      element.removeEventListener(eventName, eventListener);
    };
  }, [eventName, handler, element]);
}

// Usage example
export default function App() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setCount((prevCount) => prevCount + 1);
  };

  useEventListener("click", handleClick);

  return (
    <div>
      <h2>Click Count: {count}</h2>
      <p>Click anywhere in the window to increment the count.</p>
    </div>
  );
}

`useFocus()`

import { useRef, useState, useEffect, useCallback } from "react";

function useFocus() {
  const [isFocus, setIsFocus] = useState(false);
  const focusRef = useRef(null);
  const handleFocus = useCallback(() => {
    setIsFocus(true);
  }, []);
  const handleBlur = useCallback(() => {
    setIsFocus(false);
  }, []);

  useEffect(() => {
    const node = focusRef.current;

    setIsFocus(document.activeElement === node);

    if (node) {
      node.addEventListener("focus", handleFocus);
      node.addEventListener("blur", handleBlur);
    }

    return () => {
      node.removeEventListener("focus", handleFocus);
      node.removeEventListener("blur", handleBlur);
    };
  }, [focusRef.current]);

  return [focusRef, isFocus];
}

/* Usage example */

export default function App() {
  const [focusRef, isFocus] = useFocus();

  return (
    <div>
      <input ref={focusRef} value={isFocus} />
    </div>
  );
}

`useHover()`

import { useState, useRef, useEffect, useCallback } from "react";

function useHover() {
  const [isHovered, setIsHovered] = useState(false);
  const ref = useRef(null);
  const handleMouseEnter = useCallback(() => {
    setIsHovered(true);
  }, []);
  const handleMouseLeave = useCallback(() => {
    setIsHovered(false);
  }, []);

  useEffect(() => {
    setIsHovered(false);

    const node = ref.current;

    if (node) {
      node.addEventListener("mouseenter", handleMouseEnter);
      node.addEventListener("mouseleave", handleMouseLeave);

      return () => {
        node.removeEventListener("mouseenter", handleMouseEnter);
        node.removeEventListener("mouseleave", handleMouseLeave);
      };
    }
  }, [ref.current, handleMouseEnter, handleMouseLeave]);

  return [ref, isHovered];
}

/* Usage example */

export default function App() {
  const [inputRef, isHovered] = useHover();

  return (
    <div>
      <input ref={inputRef} value={isHovered} />
    </div>
  );
}

`useKeyPress()`

import { useState, useEffect, useCallback } from "react";

function useKeyPress(targetKey) {
  const [keyPressed, setKeyPressed] = useState(false);
  const handleKeyDown = useCallback((event) => {
    if (event.key === targetKey) {
      setKeyPressed(true);
    }
  }, []);
  const handleKeyUp = useCallback((event) => {
    if (event.key === targetKey) {
      setKeyPressed(false);
    }
  }, []);

  useEffect(() => {
    window.addEventListener("keydown", handleKeyDown);
    window.addEventListener("keyup", handleKeyUp);

    return () => {
      window.removeEventListener("keydown", handleKeyDown);
      window.removeEventListener("keyup", handleKeyUp);
    };
  }, []);

  return keyPressed;
}

function App() {
  const isSpacePressed = useKeyPress(" "); // Detect spacebar press
  const isEnterPressed = useKeyPress("Enter"); // Detect Enter key press

  return (
    <div>
      <h2>Key Press Demo</h2>
      <p>Press and hold the Spacebar or Enter key</p>
      <div>
        Spacebar pressed: <strong>{isSpacePressed ? "Yes" : "No"}</strong>
      </div>
      <div>
        Enter key pressed: <strong>{isEnterPressed ? "Yes" : "No"}</strong>
      </div>
    </div>
  );
}

export default App;

`usePosition()`

import { useState, useEffect, useRef } from "react";

function usePosition(ref) {
  const [position, setPosition] = useState({ top: 0, left: 0 });

  useEffect(() => {
    const updatePosition = () => {
      if (ref.current) {
        const { top, left } = ref.current.getBoundingClientRect();
        setPosition({ top, left });
      }
    };

    // Initial position update
    updatePosition();

    // Set up a resize observer to listen for position changes
    const resizeObserver = new ResizeObserver(updatePosition);
    if (ref.current) {
      resizeObserver.observe(ref.current);
    }

    // Cleanup function to disconnect the observer
    return () => {
      if (ref.current) {
        resizeObserver.unobserve(ref.current);
      }
    };
  }, [ref]); // Re-run when the ref changes

  return position;
}

function PositionDisplay() {
  const ref = useRef(null);
  const position = usePosition(ref);

  return (
    <div>
      <h2>Element Position:</h2>
      <div
        ref={ref}
        style={{
          width: "200px",
          height: "200px",
          backgroundColor: "lightblue",
          position: "relative",
        }}
      >
        Move me around!
      </div>
      <pre>{JSON.stringify(position, null, 2)}</pre>
    </div>
  );
}

export default function App() {
  return (
    <div>
      <h1>Listening to Element Position Changes</h1>
      <PositionDisplay />
    </div>
  );
}

`useToggle()`

import { useState, useCallback } from 'react';

function useToggle(on) {
  const [isToggled, setIsToggled] = useState(on);

  const toggle = useCallback(() => {
    setIsToggled((t) => !t);
  }, []);

  return [isToggled, toggle];
}

/* Usage example */

export default function App() {
  const [isToggled, toggle] = useToggle(false);

  return (
    <div>
      <button onClick={toggle}>Click to see</button>
      {isToggled && <div>There is a hidden content</div>}
    </div>
  );
}

`useWindowResize()`

import { useState, useEffect } from "react";

function useWindowResize() {
  const [windowSize, setWindowSize] = useState({
    width: window.innerWidth,
    height: window.innerHeight,
  });

  useEffect(() => {
    const handleResize = () => {
      setWindowSize({
        width: window.innerWidth,
        height: window.innerHeight,
      });
    };

    window.addEventListener("resize", handleResize);

    return () => {
      window.removeEventListener("resize", handleResize);
    };
  }, []);

  return windowSize;
}

export default function App() {
  const { width, height } = useWindowResize();

  return (
    <div style={{ position: "fixed", top: 0, right: 0 }}>
      <h4>Window Size</h4>
      <p>Width: {width}px</p>
      <p>Height: {height}px</p>
    </div>
  );
}

`useWindowScroll()`

import { useState, useEffect } from "react";

function useWindowScroll() {
  const [scrollPosition, setScrollPosition] = useState({
    scrollX: window.scrollX,
    scrollY: window.scrollY,
  });

  useEffect(() => {
    const handleScroll = () => {
      setScrollPosition({
        scrollX: window.scrollX,
        scrollY: window.scrollY,
      });
    };

    window.addEventListener("scroll", handleScroll, { passive: true });

    return () => {
      window.removeEventListener("scroll", handleScroll);
    };
  }, [handleScroll]);

  return scrollPosition;
}

// Usage example

function App() {
  const { scrollX, scrollY } = useWindowScroll();

  return (
    <div
      style={{
        position: "fixed",
        top: 10,
        right: 10,
        background: "white",
        padding: 10,
      }}
    >
      <p>Scroll X: {scrollX.toFixed(0)}px</p>
      <p>Scroll Y: {scrollY.toFixed(0)}px</p>
    </div>
  );
}

export default App;

Reference

Hiding an element - CSS challenges

Mitchell — Wed, 06 Nov 2024 07:15:14 +0000

You can find all the code in this post at the repo Github.

You can check the visual here Hiding an element - CodeSandbox

Hiding an element

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Hiding Elements</title>
    <link rel="stylesheet" href="styles.css" />
  </head>
  <body>
    <div class="display-none">Hiding elements</div>

    <div id="hidden" hidden>Hiding elements</div>

    <div class="outside-by-absolute">Hiding elements</div>

    <div class="outside-by-relative">Hiding elements</div>

    <div class="outside-by-margin">Hiding elements</div>

    <div aria-hidden="true">Hiding elements(for screen reader)</div>

    <div class="hide-by-opacacity">Hiding elements</div>

    <div class="container">
      <div class="hidden-element">This is hidden</div>
      <div class="covering-element">Covering the elements</div>
    </div>

    <div class="hide-by-clip">Hiding elements</div>

    <div class="hide-by-transform">Hiding elements</div>
  </body>
</html>

.display-none {
  display: none;
}

.outside-by-absolute {
  position: absolute;
  left: -9999px;
}

.outside-by-relative {
  position: relative;
  left: -9999px;
}

.outside-by-margin {
  margin-left: -9999px;
}

.hide-by-opacacity {
  opacity: 0;
}

.container {
  position: relative;
  width: 200px;
  height: 200px;
}

.covering-element {
  position: absolute;
  width: 100%;
  height: 100%;
  z-index: 2;
}

.hidden-element {
  position: absolute;
  width: 100%;
  height: 100%;
  z-index: 1;
}

.hide-by-clip {
  position: absolute;
  width: 200px;
  height: 200px;
  clip: rect(0px, 0px, 0px, 0px);
}

.hide-by-transform {
  transform: scale(0, 0);
}

Forem: Mitchell

The Rendering Machine: Understanding the Critical Rendering Path

The Rendering Machine: Understanding the Critical Rendering Path

Table of Contents

The Critical Rendering Path (CRP)

Why is the CRP Critical? / Why Optimize It?

What is the Rendering Strategy?

Progressive Rendering

Why is it Progressive?

When is it Too Early or Too Late to Render?

What Can Block Rendering and Hurt Performance?

Resources on the Critical Path

Types of Blocking Resources

Identifying Blocking Resources

Is Resource Blocking Necessary?

General Tips for Optimizing the CRP

Key Components of the CRP

DOM (Document Object Model)

CSSOM (CSS Object Model)

CSS Selectors

Render Tree

Layout (Reflow)

Paint (Repaint)

Alternative Perspectives: The Key Path

Tools for Analysis

Related Questions

References

My Learning Notes: Choosing the Right AI Model and Hardware

My Learning Notes: Choosing the Right AI Model and Hardware

The Core Challenge: Model vs. Hardware

Understanding the Model Side

Understanding the Hardware Side (Especially VRAM for Inference)

Making the Choice: Common Trade-offs

Don't Forget System RAM and CPU!

Tools Matter Too (Briefly)

A Quick Guide to GGUF Quantization Types (Common Ones)

Case Study: Deploying a Python AI Application with Ollama and FastAPI

Case Study: Deploying a Python AI Application with Ollama and FastAPI

Table of Contents

Connecting to the Server via SSH

Generating SSH Keys

Connecting

Cloning the Project Repository

Environment Setup

1. Installing uv (Optional but Recommended)

2. Installing Python

3. Installing Software Dependencies

Project Dependencies

Installing and Running Ollama

4. Preparing the AI Models

Uploading/Downloading Models

Building Models with Ollama

5. Setting Up Environment Variables

6. Running the Project Manually (Testing)

Deploying as a Service with systemd

Creating the Service File

Enabling and Starting the Service

Frequently Encountered Issues (FAQ)

Environment Configuration Issues

Runtime Issues

Conclusion

Semantic HTML

Semantic HTML

Semantic Elements

<article>

Example

Usage

<aside>

Example

Usage

<details>, <summary>

Example

Usage

Attribute

Event

<figure>, <figcaption>

Example

<header>, <footer>

Example

Usage

1. Installing `uv` (Optional but Recommended)

Deploying as a Service with `systemd`

`<article>`

`<aside>`

`<details>`, `<summary>`

`<figure>`, `<figcaption>`

`<header>`, `<footer>`

`<form>`

`<main>`

`<mark>`

`<nav>`

`<section>`

`<time>`

`role`

Use autograd profiler on `mean` operation

Use Pytorch profiler on `mean` operation

Implementing triton code for `torch.mean()`

`useLocalStorage()`

`useCountdown()`

`useDebounce()`

`useInterval()`

`useThrottle()`

`useTimeout()`

`useSWR()`

`useFetch()`

`useEffectOnce()`

`useIsFirstRender()`

`useIsMounted()`

`usePrevious()`

`useUpdate()`

`useUpdateEffect()`

`useBodyScrollLock()`

`useClickOutside()`

`useEventListener()`

`useFocus()`

`useHover()`

`useKeyPress()`

`usePosition()`