Hi Yasuo,
On Tue, 2014-01-14 at 06:57 +0900, Yasuo Ohgaki wrote:
> Hi Anatol,
>
> On Fri, Jan 10, 2014 at 11:58 PM, Anatol Belski <[email protected]> wrote:
>
> > https://wiki.php.net/rfc/size_t_and_int64
> >
> > The discussion time has come. The work on the feature branch continues.
> > The current patch is stable enough to be discussed.
>
>
> I haven't dive into details of this improvement, so
> I'm assuming the improvement is only for 64bit platforms from the title.
>
> There are number of subsystems that supports 64bit int. e.g. file system,
> PostgreSQL large object, time, etc. It's nicer if 64bit int is supported on
> 32bit platforms.
>
> What's the reason not to introduce larger int for 32bit platforms?
> Too much performance impact?
>
thanks for the interest on this. Such an idea existed at the start among
others, as well as introducing a new zval member for 'int64' besides
'long'. The reasons for not doing it (now), also from the todays point
of view:
- much higher patch complexity
- with more complexity the risk of not finishing the patch grows
- worse compatibility with libraries
- worse compatibility with existing extensions
- 64 bit processors are widely available
- well, the slowliness you mention, whereby i've no benchmarks at hand
I would describe the current patch already as a quantum jump for PHP,
whereby small steps are much safer. Having placeholders instead of fixed
types is a good base to do 64 bit int available on 32 bit platform.
However I guess bringing it up will take not less amount of woman/hours,
if not more. One can see the current state as an intermediate goal,
where it leads is another question.
What comes with the patch now:
- 64 bit int support across windows/linux
- 64 bit file operations across windows/linux
- size_t support for string length, that means string length can be
handled with userspace integers
- open perspectives for things like you mention
I've read your Postgres approach and that's doable even currently inside
32 bit, too. There is such functionality here and there, like ext/date.
Regards
Anatol