re2c scanner issue

17 years ago by Dmitry Stogov — view source

unread

Hi Marcus,

The ext/tokenizer/tests/token_get_all_variation17.phpt is probably the
last broken test. It has a memleak. I am not trying to fix it because
you should know it much better, also re2c scanner is not ported to HEAD
yet and you may keep changes that must be ported.

BTW PHP_5_3 became faster. Good work!

Thanks. Dmitry.

17 years ago by Marcus Boerger — view source

unread

Hello Dmitry,

Tuesday, March 25, 2008, 11:19:08 AM, you wrote:

Hi Marcus,

The ext/tokenizer/tests/token_get_all_variation17.phpt is probably the

There are probably more changes coming so there is not so much need to
change this part right now.

last broken test. It has a memleak. I am not trying to fix it because
you should know it much better, also re2c scanner is not ported to HEAD
yet and you may keep changes that must be ported.

Yep we're aware of this. Right now Scott is doing the MFB to HEAD part and
last time I talked with him he made pretty good progress. I updated a lot
of stuff in re2c to give myself more freedom in how to address the task of
bringing back multibyte support back in. I also started on the PHP side and
fixed quite a bunch of issues in the multibyte code so far. The good news
is that my normal build still works as expected.

BTW PHP_5_3 became faster. Good work!

Good to hear from others. Did you do any profiling you could share?

Best regards,
Marcus

17 years ago by Dmitry Stogov — view source

unread

Sorry, but I didn't store benchmarks before re2c patch so I can just
compare PHP_5_3 and PHP_5_2.

Drupal 20% faster
Qdig 2% faster
typo3 30% faster
wordpress 15% faster
xoops 10% faster

Not all the speedup caused by re2c scanner, but it makes significant
part of it.

Thanks. Dmitry.

Marcus Boerger wrote:

Hello Dmitry,

Tuesday, March 25, 2008, 11:19:08 AM, you wrote:

Hi Marcus,

The ext/tokenizer/tests/token_get_all_variation17.phpt is probably the

There are probably more changes coming so there is not so much need to
change this part right now.

last broken test. It has a memleak. I am not trying to fix it because
you should know it much better, also re2c scanner is not ported to HEAD
yet and you may keep changes that must be ported.

Yep we're aware of this. Right now Scott is doing the MFB to HEAD part and
last time I talked with him he made pretty good progress. I updated a lot
of stuff in re2c to give myself more freedom in how to address the task of
bringing back multibyte support back in. I also started on the PHP side and
fixed quite a bunch of issues in the multibyte code so far. The good news
is that my normal build still works as expected.

BTW PHP_5_3 became faster. Good work!

Good to hear from others. Did you do any profiling you could share?

Best regards,
Marcus

17 years ago by Marcus Boerger — view source

unread

Hello Dmitry, Johannes

wow! so we all together made pretty good progress. We really need to
announce that, maybe to make people help in getting the release straight?

marcus

Tuesday, March 25, 2008, 11:46:20 AM, you wrote:

Sorry, but I didn't store benchmarks before re2c patch so I can just
compare PHP_5_3 and PHP_5_2.

Drupal 20% faster
Qdig 2% faster
typo3 30% faster
wordpress 15% faster
xoops 10% faster

Not all the speedup caused by re2c scanner, but it makes significant
part of it.

Thanks. Dmitry.

Marcus Boerger wrote:

Hello Dmitry,

Tuesday, March 25, 2008, 11:19:08 AM, you wrote:

Hi Marcus,

The ext/tokenizer/tests/token_get_all_variation17.phpt is probably the

There are probably more changes coming so there is not so much need to
change this part right now.

last broken test. It has a memleak. I am not trying to fix it because
you should know it much better, also re2c scanner is not ported to HEAD
yet and you may keep changes that must be ported.

Yep we're aware of this. Right now Scott is doing the MFB to HEAD part and
last time I talked with him he made pretty good progress. I updated a lot
of stuff in re2c to give myself more freedom in how to address the task of
bringing back multibyte support back in. I also started on the PHP side and
fixed quite a bunch of issues in the multibyte code so far. The good news
is that my normal build still works as expected.

BTW PHP_5_3 became faster. Good work!

Good to hear from others. Did you do any profiling you could share?

Best regards,
Marcus

Best regards,
Marcus

17 years ago by Christian Schneider — view source

unread

Dmitry Stogov wrote:

Drupal 20% faster
Qdig 2% faster
typo3 30% faster
wordpress 15% faster
xoops 10% faster

Out of curiosity: I assume this is without an opcode cache?

Chris

17 years ago by dz@bitxtender.com — view source

unread

of course. how can you measure scanner performance with an opcode
cache on :p

David

Am 25.03.2008 um 14:15 schrieb Christian Schneider:

Dmitry Stogov wrote:

Drupal 20% faster
Qdig 2% faster
typo3 30% faster
wordpress 15% faster
xoops 10% faster

Out of curiosity: I assume this is without an opcode cache?

Chris

17 years ago by Marcus Boerger — view source

unread

Hello David,

Tuesday, March 25, 2008, 2:22:31 PM, you wrote:

of course. how can you measure scanner performance with an opcode
cache on :p

Note that Dmitry wrote that he did not isolate the scanner performance
alone. I would assume that the bigger parts of listed speedups are based on
other changes, going through NEWS you will find quite a bunch of changes
that have impact on speed. And most of them apply whether tehre is an
opcode cache or not.

marcus

Am 25.03.2008 um 14:15 schrieb Christian Schneider:

Dmitry Stogov wrote:

Drupal 20% faster
Qdig 2% faster
typo3 30% faster
wordpress 15% faster
xoops 10% faster

Out of curiosity: I assume this is without an opcode cache?

Chris

--

Best regards,
Marcus

17 years ago by Dmitry Stogov — view source

unread

Of course.

Dmitry.

Christian Schneider wrote:

Dmitry Stogov wrote:

Drupal 20% faster
Qdig 2% faster
typo3 30% faster
wordpress 15% faster
xoops 10% faster

Out of curiosity: I assume this is without an opcode cache?

Chris

17 years ago by Ilia Alshanetsky — view source

unread

This is without an opcode cache I presume?

Sorry, but I didn't store benchmarks before re2c patch so I can just
compare PHP_5_3 and PHP_5_2.

Drupal 20% faster
Qdig 2% faster
typo3 30% faster
wordpress 15% faster
xoops 10% faster

Not all the speedup caused by re2c scanner, but it makes significant
part of it.

Thanks. Dmitry.

Marcus Boerger wrote:

Hello Dmitry,
Tuesday, March 25, 2008, 11:19:08 AM, you wrote:

Hi Marcus,
The ext/tokenizer/tests/token_get_all_variation17.phpt is probably
the
There are probably more changes coming so there is not so much need
to
change this part right now.
last broken test. It has a memleak. I am not trying to fix it
because you should know it much better, also re2c scanner is not
ported to HEAD yet and you may keep changes that must be ported.
Yep we're aware of this. Right now Scott is doing the MFB to HEAD
part and
last time I talked with him he made pretty good progress. I updated
a lot
of stuff in re2c to give myself more freedom in how to address the
task of
bringing back multibyte support back in. I also started on the PHP
side and
fixed quite a bunch of issues in the multibyte code so far. The
good news
is that my normal build still works as expected.
BTW PHP_5_3 became faster. Good work!
Good to hear from others. Did you do any profiling you could share?
Best regards,
Marcus

--

Ilia Alshanetsky

17 years ago by Scott MacVicar — view source

unread

The opcode cache skips out the scanning, parsing and compilation steps
after the first run.

So if you have an opcode cache you're only going to see benefit the
first time before its stored.

Scott

Christian Schneider wrote:

David Z|lke wrote:

of course. how can you measure scanner performance with an opcode cache
on :p

That's what I thought. It also means my initial excitement is gone as we
(as anyone running anything but a personal home page) are using opcode
caches anyway. I basically just wanted it to be mentioned to avoid the
impression that people will actually see a 20% speed-up by this.

Chris