Hi,
Current NLS codepage is set as utf8, I'm wondeirng if this is the cause of the slower response of my FC2 system.
Anyone knows how to tweak this parameter to say iso8859-1 via a proc or a sysconfig interface/file?
Does the change actually make a difference?
On Tue, 2004-06-29 at 10:03 -0700, Ow Mun Heng wrote:
Hi,
Current NLS codepage is set as utf8, I'm wondeirng if this is the cause of the slower response of my FC2 system.
Anyone knows how to tweak this parameter to say iso8859-1 via a proc or a sysconfig interface/file?
The file you want is /etc/sysconfig/i18n. Mine was changed to make man pages and acroread work and looks like:
LANG="en_US" SUPPORTED="en_US:en" SYSFONT="lat0-sun16" SYSFONTACM="iso01"
Does the change actually make a difference?
Dunno. Try it and let us know.
Phil
On Tue, 2004-06-29 at 10:25, Phil Schaffner wrote:
On Tue, 2004-06-29 at 10:03 -0700, Ow Mun Heng wrote:
Hi,
Current NLS codepage is set as utf8, I'm wondeirng if this is the cause of the slower response of my FC2 system.
Anyone knows how to tweak this parameter to say iso8859-1 via a proc or a sysconfig interface/file?
The file you want is /etc/sysconfig/i18n. Mine was changed to make man pages and acroread work and looks like:
LANG="en_US" SUPPORTED="en_US:en" SYSFONT="lat0-sun16" SYSFONTACM="iso01"
That's where it's located. Thanks.
Does the change actually make a difference?
Dunno. Try it and let us know.
Just changed it to LANG="en_US" SUPPORTED="en_US:en" SYSFONT="latarcyrheb-sun16"
What's the SYSFONTACM for?
does it take a reboot to come into effect? I guess I'll have to find that out later.
Thanks
On Tue, 2004-06-29 at 10:47 -0700, Ow Mun Heng wrote: ...
Just changed it to LANG="en_US" SUPPORTED="en_US:en" SYSFONT="latarcyrheb-sun16"
What's the SYSFONTACM for?
That was there when I started. If it ain't broke...
does it take a reboot to come into effect?
No, but may want to restart apps or better yet X session.
Phil
From: Ow Mun Heng Ow.Mun.Heng@wdc.com Anyone knows how to tweak this parameter to say iso8859-1 via a proc or a sysconfig interface/file? Does the change actually make a difference?
It probably depend on application...modern toolkits such as gtk+ use UTF-8 as internal encoding so changing external encoding from UTF-8 to iso8859-1 actually add extra step to convert UTF-8 to/from iso8859-1 upon I/O.
-- hiura@{freestandards.org,OpenI18N.org,li18nux.org,unicode.org,sun.com} Chair, OpenI18N.org/The Free Standards Group http://www.OpenI18N.org Architect/Sr. Staff Engineer, Sun Microsystems, Inc, USA eFAX: 509-693-8356
On Tue, 2004-06-29 at 12:00, Hideki Hiura wrote:
From: Ow Mun Heng Ow.Mun.Heng@wdc.com Anyone knows how to tweak this parameter to say iso8859-1 via a proc or a sysconfig interface/file? Does the change actually make a difference?
It probably depend on application...modern toolkits such as gtk+ use UTF-8 as internal encoding so changing external encoding from UTF-8 to iso8859-1 actually add extra step to convert UTF-8 to/from iso8859-1 upon I/O.
Well... then tell me this..
how come FC2 seems(IS) slower compared to my original RH9 install. I was using iso8859-1 then and utf8 now.
I remember reading that that's one reason why it was slow, so I'm just giving it a shot.
I've just rebooted my notebook and I'll see how things goes with en_us. (for some reason gkrellm was hanging/sucking up my processor)
Ow Mun Heng said:
On Tue, 2004-06-29 at 12:00, Hideki Hiura wrote:
From: Ow Mun Heng Ow.Mun.Heng@wdc.com Anyone knows how to tweak this parameter to say iso8859-1 via a proc or a sysconfig interface/file? Does the change actually make a difference?
It probably depend on application...modern toolkits such as gtk+ use UTF-8 as internal encoding so changing external encoding from UTF-8 to iso8859-1 actually add extra step to convert UTF-8 to/from iso8859-1 upon I/O.
Well... then tell me this..
how come FC2 seems(IS) slower compared to my original RH9 install. I was using iso8859-1 then and utf8 now.
Different kernel version Different Gnome version Different KDE version Different compiler used etc., etc.
Tell me this: Why is my apple slower than my original orange? :-)
On Tue, 2004-06-29 at 12:29, William Hooper wrote:
Ow Mun Heng said:
On Tue, 2004-06-29 at 12:00, Hideki Hiura wrote:
From: Ow Mun Heng Ow.Mun.Heng@wdc.com Anyone knows how to tweak this parameter to say iso8859-1 via a proc or a sysconfig interface/file? Does the change actually make a difference?
It probably depend on application...modern toolkits such as gtk+ use UTF-8 as internal encoding so changing external encoding from UTF-8 to iso8859-1 actually add extra step to convert UTF-8 to/from iso8859-1 upon I/O.
Well... then tell me this..
how come FC2 seems(IS) slower compared to my original RH9 install. I was using iso8859-1 then and utf8 now.
Different kernel version Different Gnome version Different KDE version Different compiler used etc., etc.
Tell me this: Why is my apple slower than my original orange? :-)
So.. we're going towards the bloated concept again?
Ow Mun Heng wrote:
On Tue, 2004-06-29 at 12:29, William Hooper wrote:
Ow Mun Heng said:
Well... then tell me this..
how come FC2 seems(IS) slower compared to my original RH9 install. I was using iso8859-1 then and utf8 now.
Different kernel version Different Gnome version Different KDE version Different compiler used etc., etc.
Tell me this: Why is my apple slower than my original orange? :-)
So.. we're going towards the bloated concept again?
Not exactly... The issue is the input file. In RH 9 , the input file probably was iso8859-1 and then it was processed without any conversion , as the whole system was using iso8859-1. Now in fedora , the input file has to be converted by the app to UTF8 , so this extra step means that FC will be a bit slower than a native iso8859-1 system . If the system was native UTF8 and the input file was also UTF8, it should be at least as fast as a native ISO system.
-- Pedro Macedo
On Tue, 2004-06-29 at 18:08, Pedro Fernandes Macedo wrote:
Ow Mun Heng wrote:
On Tue, 2004-06-29 at 12:29, William Hooper wrote: Tell me this: Why is my apple slower than my original orange? :-)
So.. we're going towards the bloated concept again?
Not exactly... The issue is the input file. In RH 9 , the input file probably was iso8859-1 and then it was processed without any conversion , as the whole system was using iso8859-1. Now in fedora , the input file has to be converted by the app to UTF8 , so this extra step means that FC will be a bit slower than a native iso8859-1 system . If the system was native UTF8 and the input file was also UTF8, it should be at least as fast as a native ISO system.
That I can understand. So, what I would also like to understand is how I can determine if the input is Utf8 or iso8859-1.
I think right now, Firefox/squid is having some issues. I'm seeing poor performance after switching to en_US and rebooting.
Please let me know. Thanks.
From: Pedro Fernandes Macedo webmaster@margo.bijoux.nom.br Not exactly... The issue is the input file. In RH 9 , the input file probably was iso8859-1 and then it was processed without any conversion , as the whole system was using iso8859-1. Now in fedora , the input file has to be converted by the app to UTF8 , so this extra step means that FC will be a bit slower
In general this is true, but in this case, not exactly :-).
Glibc internal encoding is UTF32/UCS4, and modern toolkits, thus major desktop apps as well, OOo, all internal encoding is UTF-8, on RH9 as well.
Even you set the locale to *.iso8859-1, and keep file contents in iso8859-1 encoding on RH9, whenever apps open it, it is converted to UTF-8 for processing upon reading, and convert back to iso8859-1 when apps saves it, even though it appeared as the whole system was using iso8859-1.
This architecture is unchanged between RH9 to FC2, so encoding conversion happens everywhere on the fly.
So regardless of RH9 or FC2, and regardless with the locale you set(*.UTF-8 or *.iso8859-1 or whatever), at least the files encoded in UTF-8 takes less for I/O than other encodings.
Regards, -- hiura@{freestandards.org,OpenI18N.org,li18nux.org,unicode.org,sun.com} Chair, OpenI18N.org/The Free Standards Group http://www.OpenI18N.org Architect/Sr. Staff Engineer, Sun Microsystems, Inc, USA eFAX: 509-693-8356
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sorry if double, sent with old account..
*** on Wednesday 30 June 2004 03:32, Hideki Hiura wrote:
Glibc internal encoding is UTF32/UCS4, and modern toolkits, thus major desktop apps as well, OOo, all internal encoding is UTF-8, on RH9 as well.
Then, why not compiling Glibc with iso8859*, too? On my LFS I did so, this not took a lot of space more..
I changed my/etc/sysconfig/i18n to:
LANG="it_IT.ISO-8859-15" SUPPORTED="it_IT.ISO-8859-15:it_IT@euro:it_IT.UTF-8:it_IT:it" SYSFONT="latarcyrheb-sun16"
But when I start apps (e.g. xmms) by an xterm, I 've this message: Gdk-WARNING **: locale not supported by C library
Can I solve? tnx
- -- ***************************************************** * Coltivate Linux, tanto Window$© si pianta da solo * * MajaGLUG member http://www.teppisti.it * * LinuxFromScratch Compiler #12000 (ServoLinux-1.1a)* * gpg-key on x-hkp://keyserver.linux.it * *****************************************************