DEV Community: Vishal Rajput

PHP JIT Compiler

Vishal Rajput — Tue, 23 Sep 2025 06:23:47 +0000

PHP JIT Compiler: How It Works and Why It Matters

Introduction

PHP has traditionally been an interpreted language, which means that every time you run your PHP code, the Zend Engine parses and executes it line by line. With the release of PHP 8.0, a new feature called JIT (Just-In-Time) Compiler was introduced. JIT can significantly speed up certain types of operations by compiling PHP code into machine-level instructions that the CPU can execute directly.

In this blog, we’ll explore:

What JIT is and how it works in PHP
How PHP worked before JIT
A practical example showing the performance difference with and without JIT
When JIT is most effective

What is a JIT Compiler?

JIT (Just-In-Time) Compilation is a technique used by modern programming languages to improve performance. Instead of interpreting code at runtime (slower), JIT translates frequently used code paths into native machine code that the CPU can execute directly.

Benefits: Faster execution for CPU-heavy tasks, such as mathematical calculations or image processing.

Limitations: JIT is not very useful for I/O-heavy operations like database queries, file reading, or network calls, because the bottleneck is not the CPU.

Think of JIT as a “shortcut” for the CPU. It doesn’t change how PHP works logically, but it executes heavy loops or math operations much faster.

How PHP Worked Before JIT

Before PHP 8.0:

PHP code is parsed by the Zend Engine.
The code is converted into opcodes (intermediate instructions).
The Zend Virtual Machine executes these opcodes line by line.

Example:

<?php
$a = 0;
for ($i = 0; $i < 1000000; $i++) {
    $a += $i;
}
echo $a;

The loop above is interpreted opcode by opcode, which adds overhead for each iteration.

PHP could be speed up using OPcache, which caches the opcodes in memory to avoid parsing every time, but the interpretation step still exists.

How PHP Works With JIT

With JIT enabled:

PHP still generates opcodes.
Monitoring which parts of the code run often (hot code).
Compiling just those parts into native machine code.
Keeping less-used code in interpreted form (no compilation cost wasted).
The CPU executes the machine code directly, skipping the Zend VM overhead.
This is especially beneficial for CPU-heavy operations like math, graphics, or scientific computations.

Loop Example: With vs Without JIT

Even though we cannot run JIT in your current WAMP setup, here’s a benchmark example showing the expected time difference:

<?php
function heavyCalc($n) {
    $sum = 0;
    for ($i = 0; $i < $n; $i++) {
        $sum += sqrt($i); // CPU-heavy math operation
    }
    return $sum;
}

$start = hrtime(true);
$result = heavyCalc(1000000000);
$end = hrtime(true);

echo "Result: $result\n";
echo "Execution Time: " . (($end - $start) / 1e+9) . " seconds\n";

Results Scenario Execution Time (approx.) Without JIT 23.55 seconds With JIT 13.26 seconds

Observation: There's literally a difference of 10 seconds.

Note: JIT does not significantly improve performance for database queries or other I/O operations, because the bottleneck there is not CPU-bound.

Key Takeaways

PHP 8+ JIT allows PHP to execute mathematical and CPU-heavy operations much faster.

Normal web applications that rely on DB queries or API calls may not see a noticeable speed-up.

JIT works by compiling hot code paths into machine instructions for the CPU.

Benchmarks show that heavy loops or math operations benefit the most from JIT.

Conclusion

PHP JIT is a powerful addition to PHP 8+, especially for developers working on computational-heavy applications like simulations, games, or image processing. While it doesn’t replace traditional performance optimization for web applications, it opens up new possibilities for CPU-bound PHP programs.

By understanding how JIT works and where it is effective, developers can write more optimized PHP code for scenarios that benefit the most from native execution.

Understanding SOLID Principles

Vishal Rajput — Fri, 19 Sep 2025 05:22:46 +0000

When we build software, the way we organize classes and code matters a lot. Good design makes programs easier to fix, grow, and understand. The SOLID principles are five important rules that help programmers write cleaner and safer code. Let’s break them down with simple explanations and examples.

1. Single Responsibility Principle (SRP)

A class should only do one job. And it should have Only one reason to change. Don’t make one class handle too many things. Each class should focus on a single task.

Why: If a class does too much, changing one part can accidentally break another.

// Wrong: It Does two jobs
class UserService {
    void createUser(User user) { 
        /* save to DB */ 
    }
    void sendWelcomeEmail(User user) { 
        /* email logic */ 
    }
}

// Right: Split into two classes
class UserRepository {
    void save(User user) { /* save to DB */ }
}

class EmailService {
    void sendWelcomeEmail(User user) { /* email logic */ }
}

2. Open/Closed Principle (OCP)

Code should be easy to extend, but you shouldn’t have to change old code. In Simple words: Extending new functionality should not need to change business logic OR Add new features without Modifying tested code.

Why: Keeps your system safer and easier to grow.

// Wrong: Adding a new method means editing this class
class PaymentProcessor {
    void pay(String method) {
        if (method.equals("credit")) { /* credit card */ }
        else if (method.equals("paypal")) { /* PayPal */ }
    }
}

// Right: Add new payment types without changing old code
interface PaymentMethod { void pay(); }

class CreditCardPayment implements PaymentMethod {
    public void pay() { /* credit card logic */ }
}

class PayPalPayment implements PaymentMethod {
    public void pay() { /* PayPal logic */ }
}

class PaymentProcessor {
    void process(PaymentMethod payment) { payment.pay(); }
}

3. Liskov Substitution Principle (LSP)

Child classes should work like their parent classes without causing problems. If something works for a parent class, it should also work for a child class.

Why: Keeps your program predictable and safe.

// Wrong: Ostrich is a bird but can’t fly
class Bird { void fly() { } }
class Ostrich extends Bird { void fly() { throw new UnsupportedOperationException(); } }

// Right: Separate flying birds from non-flying birds
interface Bird {
  void wings();
}

interface FlyingBird extends Bird { void fly(); }

class Sparrow implements FlyingBird {
    public void wings() { /* sparrow has wings */ }
    public void fly() { /* sparrow flies */ }
}

class Ostrich implements Bird { 
    public void wings() { /* Ostrich has wings */ }
    /* no fly method needed */ 
}

4. Interface Segregation Principle (ISP)

Don’t force classes to use methods they don’t need. It’s better to have small, specific interfaces instead of one big one.

Why: Saves classes from having useless code.

// Wrong: Printer doesn’t need scan or fax
interface Machine {
    void print();
    void scan();
    void fax();
}

class Printer implements Machine {
    public void print() { }
    public void scan() { throw new UnsupportedOperationException(); }
    public void fax() { throw new UnsupportedOperationException(); }
}

// Right: Smaller, focused interfaces
interface Printer { void print(); }
interface Scanner { void scan(); }
interface Fax { void fax(); }

class BasicPrinter implements Printer {
    public void print() { }
}

class MultiFunctionPrinter implements Printer, Scanner, Fax {
    public void print() { }
    public void scan() { }
    public void fax() { }
}

5. Dependency Inversion Principle (DIP)

Depend on ideas, not details. Classes should use interfaces or abstract classes, not fixed code.

Why: Makes systems easier to change and test.

// Wrong: Always stuck with MySQL
class UserService {
    private MySQLUserRepository repo = new MySQLUserRepository();
    void createUser(User user) { repo.save(user); }
}

// Right: Can switch databases easily
interface UserRepository { void save(User user); }

class MySQLUserRepository implements UserRepository {
    public void save(User user) { /* MySQL logic */ }
}

class MongoUserRepository implements UserRepository {
    public void save(User user) { /* Mongo logic */ }
}

class UserService {
    private UserRepository repo;
    public UserService(UserRepository repo) { this.repo = repo; } 
    /* Now its depend on Abstraction instead lower level module */
    void createUser(User user) { repo.save(user); }
}

Summary

SRP => One class, one job.

OCP => Add new features without changing old code.

LSP => Subclasses should act like their parent classes.

ISP => Use small, simple interfaces.

DIP => Depend on ideas, not details.

Conclusion

Following the SOLID principles helps make software easier to change, test, and keep working as it grows. Even though the names sound big, the ideas are simple: write code that is clear, focused, and easy to build on later.

DNS LOOKUP

Vishal Rajput — Mon, 15 Sep 2025 11:03:25 +0000

When you type www.google.com in your browser, have you ever wonder how your computer magically know about where the google server are?

That's where DNS Lookup comes in, it’s like the phonebook of the internet, translating human-friendly domain names into machine-readable IP addresses.

What is DNS Lookup

DNS (Domain name system) is system that maps the human readable domain(www.google.com) to actuall server IP Address(8.8.8.8).

It is a process that our system perform to get the IP Address behind domain name. Without it, you’d need to remember long strings of numbers instead of simple names.

Types of DNS loopup

1) Forward DNS Lookup:

It map the domain name to server IP Address.

Example:

www.google.com //Domain
8.8.8.8 //Output

This is what happen when you open a website in your browser.

2) Reverse DNS Lookup

It map the IP Address → domain name.

Example:

nslookup 8.8.8.8 //Bash Command
dns.google //output

Often used for spam filtering, logging, and security.

Process of DNS Lookup

Whenever you type a web address in you browser you computer doesn't get the Server IP Address Magically Instead it follows some steps including:

1) Browser Cache:

When you visit a website, your browser temporarily stores its IP address.
If you revisit the site within that time frame,

the Browser says:

Hey, I already know this IP! No need to ask anyone.

and uses the stored IP to connect directly, skipping the next steps. Otherwise, it proceeds to check the OS Cache.

2) OS Cache:

If browser doesn't know then it asks the Operating system (Windows, Mac or Linux).
Your operating system keeps a small cache of domain to IP mappings.
On windows you can check it using

ipconfig /displaydns

This will display all the DNS entries currently stored in your OS cache.
If the OS doesn’t have the answer either, the process moves to the next step.

3) Router / ISP Cache

If the OS also doesn’t know, the query travels to your home router or ISP’s (Internet Service Provider) DNS cache.

ISPs usually store a huge DNS cache because thousands of users often visit the same sites (Google, Facebook, etc.).

If the Router / ISP also doesn't have answer, process moves to next step.

4) Recursive DNS Server

If no cache has the answer, your ISP forwards the request to a recursive DNS server (sometimes also called a resolver).

Think of it as a detective:

I don’t know the answer, but I’ll ask around until I find it.

This server does the heavy lifting of contacting other DNS servers on your behalf.

5) Root DNS Servers

The root servers don’t know the exact IP of a website.

Instead, they act like directory assistants.

They look at the last part of the domain (the extension, like .com, .org, .in, etc.).

Based on this extension, they guide the query to the right TLD (Top-Level Domain) server.

Example:

You search for example.com.
The root server checks: “This ends with .com.”
Then it says: “Go ask the .com TLD servers; they’ll know who manages example.com.”

6) TLD Servers

Once the Root Server directs the query to the correct category (for example, .com), the TLD Servers take over.

TLD (Top-Level Domain) Servers manage all the domains under that extension (.com, .org, .net, .in, etc.).

But here’s the catch:

They don’t know the exact IP address of the website you’re looking for.
Instead, they know which Authoritative DNS Server is responsible for that specific domain.

7) Authoritative DNS Server

This is the final authority in the DNS lookup chain.

It’s managed by the domain’s owner or hosting provider (for example, if you bought your domain from GoDaddy or host it on AWS, their DNS server usually acts as authoritative).

The Authoritative DNS server knows the actual IP address of the website because it holds the domain’s DNS records (like A record, CNAME, MX, TXT, etc.).

In simple words:

They are the ones who say:

Yes, this domain belongs to me, and here’s its exact IP address.

8) Response & Caching

Once the Authoritative DNS Server provides the IP address, that information travels back through the entire chain:
Authoritative Server → TLD Server → Root Server → Recursive Resolver → ISP → OS → Browser.

Finally, your browser has the IP address it needs and can connect directly to the website’s server.🎉

To avoid repeating this long journey every time, the result is cached at multiple layers:

Browser Cache → remembers the IP for a short while.

OS Cache → stores DNS entries system-wide.

ISP / Recursive Resolver Cache → keeps answers for many users.

Example

You search for example.com.
The Root Server sends you to the .com TLD servers.
The .com TLD servers say: “The authoritative DNS server for example.com is at ns1.exampledns.com.”
Finally, the Authoritative Server looks into its database and replies: “example.com = 93.184.216.34.”

Conclusion

Every time you open a website, your device quietly goes through a well-orchestrated journey — from checking its own cache to asking root, TLD, and authoritative servers — all just to find the correct IP address. This entire process, called DNS Lookup, usually happens in milliseconds, but without it, the internet would feel impossible to use.

By understanding how DNS Lookup works, you can better appreciate:

Why websites load faster after the first visit (thanks to caching).
Why DNS errors sometimes occur (when servers can’t resolve the IP).
Why TTL and DNS management matter for developers and businesses.

In short, DNS is the hidden backbone of the internet — making sure that the names we type are always translated into the machines’ language of numbers, so we can browse, connect, and explore without ever thinking twice.

React Re-render Behind the scene.

Vishal Rajput — Fri, 12 Sep 2025 04:28:07 +0000

import { useState } from 'react'
const App = () => {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setCount(count + 1);
    console.log(count);
  }

  return(
    <button onClick={handleClick}>Click Me</button>
  )
}

export default App

When I first ran this code and clicked the button, I noticed that the console logged the previous value of count. I always wondered why this happened-because I was updating the state by incrementing it by 1. However, the console didn't show the latest value, only the old one.
But that's not the case - it happens because of re-rendering. In React, re-rendering occurs whenever we update the state value. However, that doesn't mean React re-renders immediately with the new value. Instead, it follows a series of steps.

Whenever React encounters setState(), it schedules a re-render. After all synchronous code has finished executing, React then carries out the re-rendering process. This includes:

Creating the Virtual DOM with the updated state.
Comparing it with the previous Virtual DOM (diffing).
Updating only the necessary parts of the actual DOM (reconciliation).

It's just like a team leader telling a developer:

"Do this task, but only after you finish your current pending work."

So as per our example code:

const [count, setCount] = useState(0);

const handleClick = () => {
   setCount(count + 1);
   console.log(count);
}

When we click the button, React encounters setState() and schedules a re-render. It then moves on to the next line: console.log(count). At this moment, the value of count is still 0, so React logs 0 in the console.

After logging, there's no more code left to execute inside the function. Only then does React begin the re-rendering process, and the component is rendered again with the updated value of count.

Conclusion

This is why you see the "previous" value in the console when updating state. React doesn't block execution and update the state immediately - it schedules the update, finishes the current synchronous work, and only then re-renders the component with the new state.