Performance

Measured at Pune on an Apple M3 Max laptop under Node 24, with three builds side by side: the published 4.3.1 and 5.3.0 packages from npm, and the 5.4.0 build. Each configuration ran in 11 separate processes per build, with the builds interleaved so that a scheduling stall lands on all of them, and every figure is the median. Two pure-arithmetic controls come out at 1.0× across the three builds, so the differences below are the library's, not the machine's.

Every absolute time on this page comes from the TypeScript build. Go has not been timed with this harness: its only figures here are the 5.4 speedup ratios, which come from a separate measurement. Treat the numbers as rough guidance rather than a spec, because they move with hardware, latitude and date.

Distinct days is what a calendar scan costs, where no call can reuse the last one. Same day repeated is what a UI that re-renders one date sees. The first two columns are the 5.4.0 build, and the last two the published 5.3.0 package on the same calls.

5.4.0 runs a default day ~1.4× faster than 5.3.0, and a repeated day ~1.9× faster. A repeated sections: [] call without end times is ~3.2× faster, and a repeated getInstantPanchang ~7×. Against 4.3.1, a default day is ~20× cheaper and a repeated day ~66×.

The two levers

Most of the cost is ephemeris evaluation, so the lever that saves real time is the one that skips ephemeris work.

Narrowing the work

PanchangSection lists the four optional blocks. Everything else a daily panchang returns is arithmetic over the sunrise, sunset and next-sunrise times, so it is always computed. That covers the five elements, the slot systems, muhurtas, the fixed inauspicious periods (Rahu Kalam, Gulika Kalam, Yamaganda, Dur Muhurta, Ganda Mula and Panchaka), and masa, samvat and rashi. Skipping any of it would save nothing.

// Everything (default).
getDailyPanchang(date, loc, { timezone: 330 });

// Festivals only — no moonset, no Varjyam or Panchaka-Rahita windows.
// Moonrise and Bhadra still arrive: festival detection needs them.
getDailyPanchang(date, loc, {
  timezone: 330,
  sections: ['festivals', 'eclipse'],
});

// Cheapest useful call: elements, slots, muhurtas and the fixed inauspicious
// periods only. Those are arithmetic on the sunrise triplet and are always
// computed.
getDailyPanchang(date, loc, {
  timezone: 330,
  sections: [],
  computeEndTimes: false,
});

Repeated calls and the range helpers

Repeating a call for the same location and day is cheaper, and sunrise is single-valued: two calls for the same day give exactly the same time. Range helpers get the same benefit.

• computeEkadashiDatesForYear reads only the tithi at sunrise: ~16 ms for a full year, against ~19 ms in 5.3.0 and ~2,410 ms in 4.3.1.
• computeFestivalsInRange keeps only 'festivals' and 'eclipse', skips the end times, and stops each day once its festival list is complete: ~79 ms/year, against ~136 in 5.3.0 and ~2,230 in 4.3.1.
• computeSankrantisForYear scans one solar longitude per day and bisects the 12 transits: ~2.8 ms/year, against ~3.3 in 5.3.0 and ~160 in 4.3.1.

Where v5 is still slower

The ephemeris series are about three times more accurate against JPL DE441 than the 4.3.1 ones. Evaluating them is sine-bound, so more terms cost proportionally more time. 5.4 made each sine and cosine cheaper, which narrows the gap to 4.3.1 without closing it.

• A chart is fifteen full-accuracy planet evaluations: five planets, each at the birth instant and at two retrograde probes. That is what buys Mercury 6.50″ → 0.30″ against DE441, and why computeRashiChart and computeNavamsa still cost nearly twice what they did in 4.3.1.
• computeBhava computes the lagna and the cusps and nothing else. 5.3 also computed all nine planet positions, which the cusps never read, so a house chart cost as much as a whole birth chart. It is ~50× faster than in 5.3.0, back to a few microseconds as in 4.3.1.
• computeShadbala and computeBhavaBala are ~3.7× and ~3.6× faster than in 4.3.1, because v5 computes the positions once and reuses them.
• A raw getSiderealSunLongitude call on a new instant is still slower than in 4.3.1, and getSiderealMoonLongitude no longer is. The documented workflows go through the caches and come out faster overall. You only see this in tight loops over distinct instants, and the range APIs are the better choice there.

What 5.4 made faster

Most of the causes were repeated work. New-moon searches and planet positions were recomputed across days and charts, and are now kept in bounded caches keyed by every input, so no result depends on which calls ran before it. House cusps computed nine planet positions they never read. The converters and table builders built whole days to read four labels. Sade Sati sampled Saturn at steps where it cannot change sign, and a timezone formatter was rebuilt on every call.

One change was not about repeated work. In TypeScript, the sine and cosine behind every series evaluation passed their reduced argument through module-level variables. They now keep it in locals, which V8 can hold unboxed, and run the same operations in the same order. That change alone accounts for the rashi, navamsa, Shadbala and Bhava Bala rows above, where every call is a new birth instant and no cache is hit. It is also most of the gain in the Ekadashi and Sankranti helpers and more than half of it on a distinct default day. The caches account for nearly all of the gain on a repeated day.

None of it changed output: across the library's tests, every value and every built table is byte-identical with and without the speed work. 5.4 does move some values, as correctness fixes listed in Upgrading 5.3 → 5.4. The 5.3.0 figures on this page time the published package, so the comparison spans those fixes too.

The table below is a separate measurement on the same machine: 5.3 against 5.4 in both languages, with the two builds alternating, as medians. Each figure is a ratio, the time before divided by the time after, not an absolute time. It uses its own loops and inputs, so its ratios do not match the tables above, and for computeBhava they are far apart: 12× here against ~50× in the chart section.

React Native / Hermes

The library works with Expo and bare React Native on the Hermes engine. Pass timezone as a number. IANA strings need Intl, which older Hermes versions do not have. Render in two passes to keep the UI smooth:

import { getDailyPanchang } from 'panchang-ts';
import { InteractionManager } from 'react-native';

// Pass 1 — cheapest useful result: elements, slots, muhurtas.
const fast = getDailyPanchang(date, location, {
  timezone: 330,
  sections: [],
  computeEndTimes: false,
});
setState(fast);

// Pass 2 — background, everything.
InteractionManager.runAfterInteractions(() => {
  setState(getDailyPanchang(date, location, { timezone: 330 }));
});

The TypeScript timings above are Node measurements. Hermes figures will be published once they are measured on a device. The shape of the cost carries over: ephemeris math dominates, so the sections and computeEndTimes levers save about the same proportion on any runtime. Built tables are compact on purpose, because parse time and memory are what hurt on Hermes. See the table pattern.