DateTime-Lite
view release on metacpan or search on metacpan
When measuring the "TimeZone" class in isolation, the component that
actually handles date arithmetic, "DateTime::Lite::TimeZone" is lighter
(~16 MB vs ~19 MB) because it does not pre-load all Olson zone data into
RAM.
"DateTime::TimeZone" pre-loads all IANA Olson definitions into memory on
the first "new()" call (roughly 3-4 MB of compiled Perl structures on
top of the module overhead). "DateTime::Lite::TimeZone" queries a
compact SQLite database on demand and keeps those structures on disk.
CPU throughput (10,000 iterations, µs per call)
DateTime 1.66 DateTime::Lite
------- ------------- --------------
new( UTC ) ~13 µs ~10 µs
new( named zone, string ) ~25 µs ~64 µs (*)
new( named zone, all caches enabled ) ~25 µs ~14 µs
now( UTC ) ~11 µs ~10 µs
year + month + day + epoch ~0.5 µs ~0.4 µs
clone + add( days + hours ) ~35 µs ~25 µs
strftime ~3.5 µs ~3.6 µs
TimeZone->new (warm, no mem cache) ~2 µs ~19 µs (*)
wins on both startup time (~120 ms vs ~320 ms) and memory (~19 MB vs
~28 MB).
Running the benchmark
A self-contained benchmark script is included in the distribution:
cd DateTime-Lite-vX.X.X
perl Makefile.PL && make # make sure the XS code is compiled
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl
# More iterations for stable numbers:
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --iterations 50000
# Machine-readable CSV output:
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --csv > results.csv
USAGE
0-based Versus 1-based Numbers
"DateTime::Lite" follows a simple rule for 0-based vs. 1-based numbers.
Month, day of month, day of week, and day of year are 1-based. Every
1-based method also has a "_0" variant. For example, "day_of_week"
README-ja-JP.md view on Meta::CPAN
## ãã³ããã¼ã¯ã®å®è¡
èªå·±å®çµãããã³ããã¼ã¯ã¹ã¯ãªãããé
å¸ç©ã«å«ã¾ãã¦ãã¾ãã
cd DateTime-Lite-vX.X.X
perl Makefile.PL && make # XS ã³ã¼ããã³ã³ãã¤ã«ããã¦ãããã¨ã確èªãã¾ã
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl
# ããå®å®ããæ°å¤ãå¾ãããã«å復忰ãå¢ãã:
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --iterations 50000
# æ©æ¢°å¯èªãª CSV åºå:
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --csv > results.csv
# ä½¿ç¨æ¹æ³
## 0èµ·ç¹ã®æ°å¤ã¨1èµ·ç¹ã®æ°å¤
`DateTime::Lite`ã¯ã0èµ·ç¹ã¨1èµ·ç¹ã®æ°å¤ã«ã¤ãã¦åç´ãªè¦åã«å¾ãã¾ãã
DateTime 1.66 DateTime::Lite
------- ------------- --------------
use Module (~28 MB) ~28 MB ~37 MB
TimeZone class only ~19 MB ~16 MB
The `use Module` row is somewhat misleading on its own: `DateTime::Lite` loads `DBD::SQLite`, which embeds a complete compiled SQLite engine (~14 MB of native code) regardless of how many timezone objects you create. When measuring the `TimeZone` cla...
`DateTime::TimeZone` pre-loads all IANA Olson definitions into memory on the first `new()` call (roughly 3-4 MB of compiled Perl structures on top of the module overhead). `DateTime::Lite::TimeZone` queries a compact SQLite database on demand and kee...
## CPU throughput (10,000 iterations, µs per call)
DateTime 1.66 DateTime::Lite
------- ------------- --------------
new( UTC ) ~13 µs ~10 µs
new( named zone, string ) ~25 µs ~64 µs (*)
new( named zone, all caches enabled ) ~25 µs ~14 µs
now( UTC ) ~11 µs ~10 µs
year + month + day + epoch ~0.5 µs ~0.4 µs
clone + add( days + hours ) ~35 µs ~25 µs
strftime ~3.5 µs ~3.6 µs
- For short-lived scripts and command-line tools, `DateTime::Lite` wins on both startup time (~120 ms vs ~320 ms) and memory (~19 MB vs ~28 MB).
## Running the benchmark
A self-contained benchmark script is included in the distribution:
cd DateTime-Lite-vX.X.X
perl Makefile.PL && make # make sure the XS code is compiled
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl
# More iterations for stable numbers:
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --iterations 50000
# Machine-readable CSV output:
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --csv > results.csv
# USAGE
## 0-based Versus 1-based Numbers
`DateTime::Lite` follows a simple rule for 0-based vs. 1-based numbers.
lib/DateTime/Lite.pm view on Meta::CPAN
DateTime 1.66 DateTime::Lite
------- ------------- --------------
use Module (~28 MB) ~28 MB ~37 MB
TimeZone class only ~19 MB ~16 MB
The C<use Module> row is somewhat misleading on its own: C<DateTime::Lite> loads C<DBD::SQLite>, which embeds a complete compiled SQLite engine (~14 MB of native code) regardless of how many timezone objects you create. When measuring the C<TimeZone>...
C<DateTime::TimeZone> pre-loads all IANA Olson definitions into memory on the first C<new()> call (roughly 3-4 MB of compiled Perl structures on top of the module overhead). C<DateTime::Lite::TimeZone> queries a compact SQLite database on demand and ...
=head2 CPU throughput (10,000 iterations, µs per call)
DateTime 1.66 DateTime::Lite
------- ------------- --------------
new( UTC ) ~13 µs ~10 µs
new( named zone, string ) ~25 µs ~64 µs (*)
new( named zone, all caches enabled ) ~25 µs ~14 µs
now( UTC ) ~11 µs ~10 µs
year + month + day + epoch ~0.5 µs ~0.4 µs
clone + add( days + hours ) ~35 µs ~25 µs
strftime ~3.5 µs ~3.6 µs
lib/DateTime/Lite.pm view on Meta::CPAN
=back
=head2 Running the benchmark
A self-contained benchmark script is included in the distribution:
cd DateTime-Lite-vX.X.X
perl Makefile.PL && make # make sure the XS code is compiled
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl
# More iterations for stable numbers:
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --iterations 50000
# Machine-readable CSV output:
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --csv > results.csv
=head1 USAGE
=head2 0-based Versus 1-based Numbers
C<DateTime::Lite> follows a simple rule for 0-based vs. 1-based numbers.
lib/DateTime/Lite/JA.pod view on Meta::CPAN
=head2 ãã³ããã¼ã¯ã®å®è¡
èªå·±å®çµãããã³ããã¼ã¯ã¹ã¯ãªãããé
å¸ç©ã«å«ã¾ãã¦ãã¾ãã
cd DateTime-Lite-vX.X.X
perl Makefile.PL && make # XS ã³ã¼ããã³ã³ãã¤ã«ããã¦ãããã¨ã確èªãã¾ã
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl
# ããå®å®ããæ°å¤ãå¾ãããã«å復忰ãå¢ãã:
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --iterations 50000
# æ©æ¢°å¯èªãª CSV åºå:
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --csv > results.csv
=head1 ä½¿ç¨æ¹æ³
=head2 0èµ·ç¹ã®æ°å¤ã¨1èµ·ç¹ã®æ°å¤
C<DateTime::Lite>ã¯ã0èµ·ç¹ã¨1èµ·ç¹ã®æ°å¤ã«ã¤ãã¦åç´ãªè¦åã«å¾ãã¾ãã
scripts/benchmark.pl view on Meta::CPAN
## - CPU / wall-clock time for common operations
## - Resident memory (RSS) after loading
##
## Architecture: the parent process forks before loading any module.
## Each child loads only its own module set, measures what it needs,
## serialises results to a temp file, and exits. The parent aggregates
## and prints. This guarantees a clean %INC for every measurement,
## avoiding false results caused by shared module state.
##
## Usage:
## perl -Iblib/lib -Iblib/arch scripts/benchmark.pl [--iterations N]
## perl -Iblib/lib -Iblib/arch scripts/benchmark.pl --csv
##
## DateTime must be installed on the system.
## DateTime::Lite is loaded from blib/ (run `make` first).
##----------------------------------------------------------------------------
use v5.10.1;
use strict;
use warnings;
# These modules are loaded BEFORE any fork so they are available in every
# child via copy-on-write. They must not pull in DateTime or DateTime::Lite.
use POSIX qw( WIFEXITED WEXITSTATUS );
use File::Temp qw( tempfile );
use Getopt::Long qw( GetOptions );
use Scalar::Util qw( looks_like_number );
my $ITERATIONS = 10_000;
my $CSV = 0;
GetOptions(
'iterations=i' => \$ITERATIONS,
'csv' => \$CSV,
) or die "Usage: $0 [--iterations N] [--csv]\n";
# Snapshot @INC before any fork so children inherit it correctly.
my @INC_SNAP = @INC;
# ---------------------------------------------------------------------------
# IPC helpers
# ---------------------------------------------------------------------------
# Run a closure in a child process.
# The closure receives a CODE ref it must call with a hashref of results.
scripts/benchmark.pl view on Meta::CPAN
$dt->{rss_after_tz}, $dtl->{rss_after_tz}, 'kB' );
row( 'RSS: use TimeZone alone',
$dt_tz->{rss_tz}, $dtl_tz->{rss_tz}, 'kB' );
row( 'Modules after first named zone construction',
$dt->{mods_after_tz}, $dtl->{mods_after_tz}, 'modules' );
print " Note: DT::TimeZone loads one .pm per zone on first use;\n"
. " DTL::TimeZone uses SQLite so module count stays flat.\n"
. " DTL RSS includes DBD::SQLite (~14 MB compiled native code).\n"
unless $CSV;
section( "CPU / wall-clock ($ITERATIONS iterations, µs per call, measured in clean fork)" );
header();
row( 'new( UTC )',
fmt( $dt->{new_utc_wall} / $N * 1e6 ),
fmt( $dtl->{new_utc_wall}/ $N * 1e6 ), 'µs/call' );
row( 'new( named zone, string )',
fmt( $dt->{new_ny_wall} / $N * 1e6 ),
fmt( $dtl->{new_ny_wall} / $N * 1e6 ), 'µs/call' );
row( 'new( named zone, mem cache enabled )',
fmt( $dt->{new_ny_wall} / $N * 1e6 ),
scripts/benchmark.pl view on Meta::CPAN
=head1 NAME
benchmark.pl - Compare DateTime and DateTime::Lite performance
=head1 SYNOPSIS
cd DateTime-Lite-vX.X.X
perl Makefile.PL && make
perl -Iblib/lib -Iblib/arch scripts/benchmark.pl
perl scripts/benchmark.pl --iterations 20000
perl scripts/benchmark.pl --csv > results.csv
=head1 DESCRIPTION
Forks the process before loading any module so that every measurement
runs in a clean C<%INC>. Results are serialised to temp files and
aggregated by the parent.
=head1 OPTIONS
=over 4
=item C<--iterations N>
Timing loop iterations (default: 10_000).
=item C<--csv>
Machine-readable CSV output.
=back
=cut
( run in 1.405 second using v1.01-cache-2.11-cpan-71847e10f99 )