Tuesday 03 August 2004 7:34:03 am

Are there any php compile or system setting I can tweak to reduce the amount of time spent in this stage?

--tony

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future

Tuesday 10 August 2004 6:10:37 am

Tony, Alex,

When time is consumed in string conversion from MySQL then something is not optimal configured. That's why we've added this. It can happen if e.g. you use a differente character set on your database than the rest of eZ publish. Ideally/normally this should be 0.

You should optimally make all charactersets the same. Some information about how to set character sets can be found here:

http://ez.no/ez_publish/documentation/configuration/configuration/language_and_charset/unicode_with_ez_publish

--bård

Documentation: http://ez.no/doc

Tuesday 10 August 2004 7:03:55 am

Hi,

at my installation (utf8 output, utf8 db -> mysql 4.1.2), I've following at a uncached page:

String conversion in mysql | 2.2379 sec | 32.7103% | 14326 | 0.0002 sec

total queries: 288
string conversion calls: 14.326

I've found out, that a "dummy"-method is called. (Because - of course - a conversion from utf8 to utf8 isn't necerssary). But - IMHO - it would be better to save that 14.326 dummy calls.

Kind regards,
Emil.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Tuesday 10 August 2004 7:13:15 am

Great.

It can often be a time saver to check the ini settings using the admin tool. This will let you know if you have an override or not, it have helped me many times.

--bård

Documentation: http://ez.no/doc

Tuesday 10 August 2004 7:24:37 am

I have this now...

I get this now
String conversion in mysql 0.5773 sec 34.3655% 2422 0.0002 sec

Your right emil 2422 calls is a lot.

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future

Tuesday 10 August 2004 7:33:37 am

Bard:

yes, I've mentioned that some times ago in the bug report:

http://ez.no/community/bug_reports/ezdbinterface_php_text_conversion

HTH,

Kind regards,
Emil.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Thursday 12 August 2004 3:50:44 am

Bard,

Just an update. With a few well placed cache-block tags this has been reduced.

String conversion in mysql	0.0074 sec	2.7348%	31	0.0002 sec

--tony

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future

Thursday 12 August 2004 6:50:56 am

This fix actually improved the performance on an std 3.4.1 installation on my computer with 35% when I used utf-8. So you will definetly notice it if you use unicode.

--bård

Documentation: http://ez.no/doc

Thursday 12 August 2004 7:46:35 am

Tony, I've also added another fix in svn which makes it compatible with single byte characters as well. My first patch broke that.

Here is that new code:

            if ( $this->OutputTextCodec && $this->InputTextCodec )
            {
                if ( !$this->OutputTextCodec->conversionRequired() || !$this->InputTextCodec->conversionRequired() )
                {
                    unset( $this->OutputTextCodec );
                    unset( $this->InputTextCodec );
                    $this->OutputTextCodec = null;
                    $this->InputTextCodec = null;
                }
            }

--bård

Documentation: http://ez.no/doc

Thursday 12 August 2004 8:14:06 am

utf-8 is OK allthought it would be faster if it was stored using the current internal charset (removes conversion need).
We already do this for the XML datatype but it hasn't been implemented for the other datatypes yet.

Also <i>unicode</i> is the character set but is not an encoding so cannot be used for storage, however unicode has several encodings defined.
utf-8: The most common in stored media, uses 1 to 6 bytes for storage, ie. it is variable and works seamlessly with existing 8bit string code. However it is a bit slow due to the variable size.

usc2: Stores using double-byte, much faster since lookup is constant and quite often used internally in programs. Unfortenately doing this in PHP using PHP code only could quite easily be troublesome

usc4: Similar to usc2 but uses four bytes (since the initial 2 bytes were not enough for all languages in the world, something like 21 bit is needed I believe).
there are also other encodings (like the non-standard utf-7.5) but hardly used.

So storing utf-8 in 8bit only databases is OK as long as you don't try to do text operations on them in the database.

--
Amos

Documentation: http://ez.no/ez_publish/documentation
FAQ: http://ez.no/ez_publish/documentation/faq