bk / data-ulid Goto Github PK

I haven't checked it yet, so am leaving it as a question here:

Is the binary format also lexicographically sorted?

As I rather store them as a BINARY(16) than a CHAR(26), but can only use them if the binary format also grows lexically over time.

See also:
https://en.wikipedia.org/wiki/Universally_unique_identifier#As_database_keys

Hi,

I re-wrote parts of the core of Data::ULID to suit my needs. I have two options:

• take my changes, adjust them to your codebase and send you a PR;
• put Data::ULID::Faster on CPAN.

This benchmark:

use Benchmark 'cmpthese';
use lib '.';
use ULID       ();
use Data::ULID ();


cmpthese(
  -5,
  { 'ULID text'       => sub { ULID::ulid() },
    'Data::ULID text' => sub { Data::ULID::ulid() },
  }
);

cmpthese(
  -5,
  { 'ULID binary'       => sub { ULID::ulid_bin() },
    'Data::ULID binary' => sub { Data::ULID::binary_ulid() },
  }
);

Gives this results:

                    Rate Data::ULID text       ULID text
Data::ULID text   9456/s              --            -93%
ULID text       145084/s           1434%              --
                      Rate Data::ULID binary       ULID binary
Data::ULID binary   6216/s                --              -99%
ULID binary       805650/s            12860%                --

Do you have any preference? I can do either of the options above.

Thank you,

This is dependency graph for Data::ULID:

DateTime dependency tree is huge, and it is only directly used in ulid_date function (not counting isa check in _ulid, as we don't use it there directly).

Would you accept a PR that remove DateTime dependency? How it would work is:

• during module compilation (in a BEGIN block) we try to load DateTime
• during ulid_date execution we check whether DateTime was loaded, and we throw exception if it wasn't (something like "using ulid_date function requires DateTime module")
• in tests, we skip all the tests requiring DateTime if we don't have DateTime installed

Hey there!

This issue is about something we may consider in the future.

As you know I have worked hard to make the ulid generation faster, and that's because I want to generate them for anything and everything in my performance-hungry project. Sadly I think we are at Perl limits already and ~130k per second may not cut it.

For this reason I am working on partial XS implementation. I have just uploaded Data::ULID::XS - this is very much work in progress, but I already have working pure C base32 encoding. Even with this little XS, ulid can already compete with Crypt::Misc::random_v4uuid:

            Rate    ulid ulid_xs    uuid
ulid    126879/s      --    -60%    -61%
ulid_xs 320655/s    153%      --     -2%
uuid    327762/s    158%      2%      --

I think I can squeeze even more (but not as much) performance out of it when I reimplement binary_ulid in XS.

This module has the same interface as Data::ULID, but will only work for ulid and binary_ulid called without arguments - in other cases it just calls Data::ULID::ulid or Data::ULID::binary_ulid instead. I don't think anything else other than generation needs that much performance. It will also only work for 64 bit systems.

The actual question is - after I fully implement it and make it stable, would you like to include my XS code in base Data::ULID distribution (making Data::ULID::XS obsolete), or keep Data::ULID implemented as-is and let XS implementation coexist?

Another solution would be to make Data::ULID use backends - like JSON::MaybeXS - but the issue I have with this is that Data::ULID already depends on CryptX, which requires XS compilation, so there's technically no reason for it to just ship Perl when XS solution exists (other than Perl code being more stable).

There's no rush, will take me some time to make it stable. Also, I'm not exactly sure if we should do it, because of the limitations mentioned above. I'm perfectly happy with having a second module with XS implementation, but that's not how XS implementations on CPAN usually work.

This version check is needed for to_bytes and from_bytes methods and it's fine, but would be nice to avoid smokers reporting a failure. Maybe set this version of Math::BigInt as a dependency even though it won't be used on 64 bit?

Hi, I've been interested in this module today.
And tried to fix the inconvenience when I use it.

If you like this I'll try to make a PR with the least changes.

the diff is here.

sub ulid_date {
-    my $ulid = shift;
+    my $ulid     = shift;
+    my %args     = @_ if @_ >= 2;
+    my $timezone = shift || 'UTC';
+    $timezone = $args{'time_zone'} if exists $args{'time_zone'};
    die "ulid_date() needs a normal or binary ULID as parameter" unless $ulid;
-    my ($ts, $rand) = _ulid($ulid);
+    my ( $ts, $rand ) = _ulid($ulid);
    $ts = _bint($ts);
-    return DateTime->from_epoch(epoch=>$ts / 1000);
+    return DateTime->from_epoch( epoch => $ts / 1000, time_zone => $timezone );
}

I've just added to accept timezones(and some tidied)

best regard.