Better performance for exe compiled with Xbase++

[lucsaffre]

Hi all,

I am author of an accounting software which is compiled using Xbase++. It works fully under wine, except that it is very, very slow. I found the http://wiki.winehq.org/Performance page and tried already certain settings:

winetricks settings list | less
winetricks mwo=enabled
winetricks fontsmooth=disable
winetricks ao=enabled

What else should I try? Do you have any quick tips out of the box?

If I prepare and post a downloadable zip file of my application, is there anybody here who will try to reproduce my problem and help me to get better performance?

Luc

[oiaohm]

http://wiki.winehq.org/FAQ#get_log

lucsaffre I guess you have looked at wine debugging log. This can tell us what the applciation is using and give us clues on what to suggest. WINEDEBUG=-all can sometime give a large lift in performance but in a major drop in debugging. wine --version is not mentioned.

[lucsaffre]

Hi oiaohm, thanks for the hints!

$ wine --version
wine-1.4.1

With no WINEDEBUG envvar set, I have the following log (for starting the exe and selecting "Exit" from its main menu.):

$ tim
fixme:font:freetype_SelectFont Untranslated charset 255
fixme:font:freetype_SelectFont Untranslated charset 255
fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = (null)
fixme:font:freetype_SelectFont Untranslated charset 255
fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = (null)
fixme:font:freetype_SelectFont Untranslated charset 254
fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = (null)
fixme:font:WineEngRemoveFontResourceEx (L"XppNat.dll", 0, (nil)): stub
$

When I set WINEDEBUG=-all then I get no log.

When I set WINEDEBUG=all (and redirect to a file) then I get a log file of 165MB. You can download the zipped full log file from my server <http://tim.saffre-rumma.net/dl/tmp/20140319.zip>, but here is the beginning of that file:

trace:heap:RtlAllocateHeap (0xbfc00000,70000061,0000041f): returning 0xbfc00138
trace:virtual:VIRTUAL_DumpView View: 0xbfc00000 - 0xbffffffftrace:virtual:VIRTUAL_DumpView (anonymous)
trace:virtual:VIRTUAL_DumpView 0xbfc00000 - 0xbfffffff c-rw-
trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x7ffe0000 00010000 3000 00000004
trace:heap:RtlAllocateHeap (0xbfc00000,70000061,0000002f): returning 0xbfc00568
trace:virtual:VIRTUAL_DumpView View: 0x7ffe0000 - 0x7ffefffftrace:virtual:VIRTUAL_DumpView (valloc)
trace:virtual:VIRTUAL_DumpView 0x7ffe0000 - 0x7ffeffff c-rw-
trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 00000230 101000 00000004
trace:virtual:map_view got mem in reserved area 0x7ffdf000-0x7ffe0000
trace:heap:RtlAllocateHeap (0xbfc00000,70000061,00000020): returning 0xbfc005a8
trace:virtual:VIRTUAL_DumpView View: 0x7ffdf000 - 0x7ffdfffftrace:virtual:VIRTUAL_DumpView (valloc)
trace:virtual:VIRTUAL_DumpView 0x7ffdf000 - 0x7ffdffff c-rw-
trace:ntdll:RtlInitializeBitMap (0x7bce21ec,0x7ffdf044,64)
trace:ntdll:RtlInitializeBitMap (0x7bce21f4,0x7ffdf154,1024)
trace:ntdll:RtlInitializeBitMap (0x7bce21fc,0x7ffdf21c,128)
trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 00004000 101000 00000004
trace:virtual:map_view got mem in reserved area 0x7ffd8000-0x7ffdc000
trace:heap:RtlAllocateHeap (0xbfc00000,70000061,00000023): returning 0xbfc005d8
trace:virtual:VIRTUAL_DumpView View: 0x7ffd8000 - 0x7ffdbffftrace:virtual:VIRTUAL_DumpView (valloc)
trace:virtual:VIRTUAL_DumpView 0x7ffd8000 - 0x7ffdbfff c-rw-
sock_init: shutdown() causes EOF
wineserver: starting (pid=8381)
0008: *fd* 01af -> 20
0009: *fd* 6 <- 20
0009: *fd* 8 <- 21
0009: init_thread( unix_pid=8378, unix_tid=8378, debug_level=1, teb=7ffd8000, entry=7ffdf000, reply_fd=6, wait_fd=8, cpu=x86 )
0009: init_thread() = 0 { pid=0008, tid=0009, server_start=1cf4332b96ab3c8 (-0.0001320), info_size=0, version=431, all_cpus=00000001 }
0.000trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 00110000 2000 00000004
0.000trace:virtual:map_view got mem in reserved area 0x110000-0x220000
0.013trace:heap:RtlAllocateHeap (0xbfc00000,70000061,0000012f): returning 0xbfc00610
0.013trace:virtual:VIRTUAL_DumpView View: 0x110000 - 0x21ffff (valloc)
0.013trace:virtual:VIRTUAL_DumpView 0x110000 - 0x21ffff --rw-
0.013trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x110000 00010000 1000 00000004
0.013trace:virtual:VIRTUAL_SetProt 0x110000-0x11ffff c-rw-
0.013trace:virtual:VIRTUAL_DumpView View: 0x110000 - 0x21ffff (valloc)
0.013trace:virtual:VIRTUAL_DumpView 0x110000 - 0x11ffff c-rw-
0.013trace:virtual:VIRTUAL_DumpView 0x120000 - 0x21ffff --rw-
0.014trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 00001000 1000 00000004
0.014trace:virtual:map_view got mem in reserved area 0x220000-0x221000
0.021trace:heap:RtlAllocateHeap (0xbfc00000,70000061,00000020): returning 0xbfc00750

Hoping for more hints.
Luc

[dimesio]

$ wine --version
wine-1.4.1

That version is old and no longer supported. Upgrade to the latest development release.

If I prepare and post a downloadable zip file of my application, is there anybody here who will try to reproduce my problem and help me to get better performance?

I can try and reproduce it. But please be more specific about exactly what is slow and how the speed compares to Windows (e.g., opening a file takes x seconds in Wine but only x in Windows).

[lucsaffre]

Upgrading to 1.6, and then to 1.7 gave indeed a tangible improvement!
Thanks for your great work, guys!

That said, it is still a little bit too slow for serious use. Before posting a downloadable (and easily installable) zip file (which might mean quite some work for me), I'll try to be more specific about what is slow. My impression is that file access is NOT the problem, but that the operations which display text to the screen are slow. And they are "interruptedly" slow, i.e. sometimes a large part of the screen builds very quickly, then there the screen freezes during a second or two, then it continues slowly, and a bit later again quickly.

Here is the log with no WINEDEBUG:

$ tim
fixme:font:freetype_SelectFont Untranslated charset 255
fixme:font:freetype_SelectFont Untranslated charset 255
fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = (null)
fixme:font:freetype_SelectFont Untranslated charset 255
fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = (null)
fixme:font:freetype_SelectFont Untranslated charset 254
fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = (null)

And again an 11 MB zip file containing a 165 MB full log for download:
http://tim.saffre-rumma.net/dl/tmp/20140319b.zip

Luc

[oiaohm]

http://support.microsoft.com/kb/165478
http://msdn.microsoft.com/en-us/library/cc194829.aspx
lucsaffre ok I have still not run the program but there is a big clue.

fixme:font:freetype_SelectFont Untranslated charset 254

I don't know how your program is generating this as there should be no charset 254. So something under windows is most likely not printing.

fixme:font:freetype_SelectFont Untranslated charset 255

This is OEM_CHARSET if you read the msdn link above you will find out its horribly defined.

Small change to your code base nuking all instances of OEM_CHARSET and replacing with DEFAULT_CHARSET will most likely cure the performance issue as that is what is happening anyhow in this operation

fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = (null)

But doing this option get_nearest_charset lookup repeatedly is insanely slow.

I don't have a clue what 254 charset is but its most likely a code bug since officially there is no charset 254 it is also been rendered as DEFAULT_CHARSET.

lucsaffre yes the advantage to testing on wine at times. Wine hates particular bad or unstable behaviours. Unstable is using OEM_CHARSET since it changes with locale setting of Windows. If you wish wine fixed to support OEM_CHARSET do feel free to open new bug and state its a performance problem not having OEM_CHARSET defined.

lucsaffre wine logs tell important stories when you can read them. Yes the log message matches the behaviour you describe.

dimesio I know this one when I saw the log. Its I curse the coder who put OEM_CHARSET in somewhere messages. Its bad code or very old programs that don't know better if you see it. If wine is spitting out fixmes OEM_CHARSET I would normally recommend users report to maker of application as well as possibly open bug with wine due to the fact OEM_CHARSET is dicey. This case we have the developer.


lucsaffre OEM_CHARSET stuff is most likely in older sections of the code base you have not visited for a fair while. Using OEM_CHARSET was not recommended in 2002 due to the multi country issues it can kick up.

[lucsaffre]

Yes, that sounds the right explanation! My Xbase++ compiler is over 10 years old, and my program uses functions to select a default font. I'll need some time to dive into the docs of Xbase++, but I'll probably be able to change my program to not use OEM_CHARSET. Thanks for your diagnosis, which was exactly the missing piece of the jigsaw puzzle!

[lucsaffre]

Hi oiaohm,

here are some new elements. The OEM charset is yes very old coding style, but I am afraid that my program cannot be converted to *not* use it. Here are some screenshots of my program:
http://tim.saffre-rumma.net/133.html

The code which selects that codepage is here:
http://code.google.com/p/tim/source/bro ... PSYSXB.PRG

Switching the codepage to DEFAULT_CHARSET or to SYMBOL_CHARSET (1) had the expected effect of getting all those box characters mangled up and (2) did NOT improve performance. I did not yet find in my code a place where it selects codepage 254.

Although my software itself is free and still being used, it requires the non-free Xbase++ compiler and is itself hopelessly obsolete, so I guess that I must continue research myself. Still grateful for every comment. I'll try to post here what I am going to learn. I definitively plan to solve these problems, but they are not of vital urgence. The documentation for the Xbase++ compiler is publically available under "Xbase++ Reference Documentation " from here: http://alaska-software.com/download/sho ... section=40

[lahmbi5678]

Hi,

please consider filing a bug in wine's bugzilla. Would it be possible for you to create a sample app as (standalone) .exe or is xbase++ needed to run it?

[oiaohm]

lucsaffre at this point as lahmbi5678 recommend open a bug report at bugs.winehq.org also I would recommend opening up a http://appdb.winehq.org/ page. This is where wine support people send people having trouble with applications for work arounds first.

I was thinking you were running like Xbase++ 2.0 or 1.9. So somewhere near modern not a 10 year old version. Due to this I would recommend testing the code base against http://harbour.github.io/ 1 to get away from the 10 year old complier number 2 possible native Linux version. Also possible on to android http://code.google.com/p/fivedroid/

If lucky there should not be too many major changes to get into harbour. If your complier is over 5 years old in most cases you have to be asking what are you doing and look around for clones.