Hi Randy,
IMO, all environment vars and compiler switches should default for
maximum performance - If a user wants profiling, tracing, debugging,
etc., they can enable them as required.
In general I don't agree that we should aim
for maximum performance. Performance is not
the only aspect of a language. It's important
but it's not above everything. Usually there
is no free performance, so something has to be
traded off, and it's pretty difficult to trade
off on behalf of users. That's why we don't
compile with -6 switch in BCC for example.
We have profiler turned off, tracing turned
off, disabling debugging completely would be
a big mistake IMO, since ppl are expecting this
as a basic feature. HB_GUI kills some compatibility
and expected features, so it cannot be turned on.
Memory tracing is an interesting thing, I'd
definitely leave it turned on for RC builds,
otherwise we are missing important input from
users, and we can disable it for final code.
Same goes for 'harbour /l' switch.
Also notice that here we may define a safe
or reasonable set of defaults, which can be
overridden in any ways by non-official binary
builders. Non-official binary builds are a
healty thing and their role is exactly to
emphasis on specific target, like performance.
Brgds,
Viktor
Randy.
At 04:43 PM 6/2/2008, you wrote:
What do you think of making this a runtime option?
(a Set())
The idea of using this macro was eliminating all possible
overhead from main HVM loop. Using and RT switch like new
set() does not make it. Anyhow current code can/should be
updated. See the note about hb_set.HB_SET_KEYPOLL I left
in main HVM loop few years ago.
That's why I was asking. But would one flag comparison
be such an overhead there?
For HB_NO_DEBUG we're talking about maybe 4-6 CPU instructions
per Harbour function call. Do we really need this? Is this
measurable?
Just like for most of others. Probably only HB_GUI is HB_NO_PROFILER
are important because pending code is executed in each HVM loop (for
each PCODE). I'll make speed test for HB_GUI to check current
difference.
Thanks Przemek.
Also HB_NO_DEBUG... I saw these were added (along with NO_TRACE)
on request last year but IMO there are better ways to squeeze
more performance out of Harbour in general. If there is someone
who so badly needs more raw VM performance there are most
probably a dozen more stuff which could be commented out
of Harbour VM/RTL. These customization can be made locally
(not on repo) unless they aren't features which give
benefit for 'lots' of users IMO.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
