On Tue, 05 May 2009, Miguel Angel Marchuet wrote:
Hi,
> 2009-01-12 15:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> * harbour/source/vm/fm.c
> * harbour/include/hbwmain.c
> * use HeapAlloc( GetProcessHeap(), ... ) instead of LocalAlloc()
> when HB_FM_WIN32_ALLOC macro is set - Toninho's tests show that
> it's a little bit more efficient - thanks.
>
> WHY YOU DON'T PUT CREDITS !!!
Because it was my code only. I didn't copied even single line from xHarbour
adding above feature. There was nothing to copy because only some WIN32
API calls were changed. I knew that xHarbour used HeapAlloc() instead of
LocalAlloc() but it was not enough for me to accept it and adopt to Harbour
without real windows tests. I was afraid that Giancarlo using LocalAlloc()
instead of suggested by MS HeapAlloc() made it intentionally as some type
of workaround for some problems. When Toninho asked me about some behavior
of memory managers in Harbour and xHarbour I asked him to make some speed
tests with HeapAlloc() which is used in xHarbour instead of LocalAlloc().
He did it and the results confirmed that it can be used to replace
LocalAlloc() with some small performance improvement. Because it was
possible that using HeapAlloc() operating on process heap GetProcessHeap()
can interact with some other code which needs some strict process heap
behavior I kept support for old LocalAlloc() covered by HB_FM_LOCALALLOC
macro.
Here is the full patch for fm.c:
Index: fm.c
===================================================================
--- fm.c (wersja 10018)
+++ fm.c (wersja 10032)
@@ -152,9 +152,15 @@
# define free( p ) dlfree( ( p ) )
# endif
#elif defined( HB_FM_WIN32_ALLOC ) && defined( HB_OS_WIN_32 )
-# define malloc( n ) ( void * ) LocalAlloc( LMEM_FIXED, ( n ) )
-# define realloc( p, n ) ( void * ) LocalReAlloc( ( HLOCAL ) ( p ), ( n
), LMEM_MOVEABLE )
-# define free( p ) LocalFree( ( HLOCAL ) ( p ) )
+# if defined( HB_FM_LOCALALLOC )
+# define malloc( n ) ( void * ) LocalAlloc( LMEM_FIXED, ( n ) )
+# define realloc( p, n ) ( void * ) LocalReAlloc( ( HLOCAL ) ( p ), ( n
), LMEM_MOVEABLE )
+# define free( p ) LocalFree( ( HLOCAL ) ( p ) )
+# else
+# define malloc( n ) ( void * ) HeapAlloc( GetProcessHeap(), 0, ( n )
)
+# define realloc( p, n ) ( void * ) HeapReAlloc( GetProcessHeap(), 0, (
void * ) ( p ), ( n ) )
+# define free( p ) HeapFree( GetProcessHeap(), 0, ( void * ) ( p ) )
+# endif
#endif
If you think that I should leave a note that HeapAlloc() were used also
in xHarbour before it was added to Harbour then I'll add it in next commit.
I hope that adding this info:
Thanks also to Miguel Angel Marchuet which 1-st used HeapAlloc()
in xHarbour.
will be enough of you. But maybe you have different proposition?
But as I can see you copied some parts of this modifications two days later
to xHarbour:
2009-01-14 11:34 UTC+0100 Miguel Angel Marchuet <miguelan...@marchuet.net>
* source\vm\fm.c
! minor optimization, 1 seg more quick speedtst, but remains one important
question
fmapi is used before its initialization (void hb_xinit( void )) I think
this function
need be called first of all.
- removed test comments.
+ Added macro HB_FM_LOCALALLOC to use LocalAlloc instead of HeapAlloc.
Microsoft says that
the use of LocalAlloc need be changed by HeapAlloc, but we leave it here
to user election.
and as usual without any information from where HB_FM_LOCALALLOC comes from.
BTW as I can see you haven't copied the whole modification so inside
source/vm/mainwin.c function WinMain() still uses LocalAlloc() - it
should be fixed.
Looks that missing notes about source of the modifications confuse even
you and you send above message though current code in both repositories
due to your synchronization is created by me. But in this particular case
there is no problem for me at all. I do not want to check from where each
macro or variable name comes from or in which project some API function
was used the 1-st time. It will be nonsense. I'm only talking about direct
code coping without information about original authors.
And I hope you will update all your ChangeLog entry in xHarbour adding notes
about authors. Nothing more nothing less.
best regards,
Przemek
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
