Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / DLLs and Performance

Author
Message
solo
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 11th Apr 2003 16:59
I have no experience with DLLs though i'm a C programmer,
so i have some things to clear:

1. Is it better using a single DLL within DBP, or should i
split functions over a several DLL and use each at a time?
(my functions itself, don't allocate any memory)

2. Can a single DLL made of several CPP files?

3. I want to call a single C++ function, and pass it memblocks ptrs.
This function uses a lot of other C++ functions (I'm trying to
put my whole DB's logic into a C++ module):
Should i do the rc workaround with only that main function?

4. My DB's main loop calls each cycle, a DLL's function that deals
with the program logic, while the DB source deals with the
graphics. Should i DELETE DLL each cycle and load it on the next
loop cycle? or may i use the same loaded DLL?

5. I read some post of hacking DB/DBP executables. Is it more safe
to use DLLs rather than DBP?

I appreciate any information i get.
[solo]
MrTAToad
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 11th Apr 2003 17:41
1. Split functions over (many) DLL's, but group relevant ones into one file. It should make modifying/updating one easier.

2. Yes

3. Dont understand...

4. Only load DLL's at the start, and delete them at the end. At any other time is silly and could slow down the program (especially if its in a loop).

5. No difference either way...

Good news everyone! I really am THAT good...
http://www.nickk.nildram.co.uk/ for great plug-ins - oh my, yes!
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 11th Apr 2003 17:49
"5. I read some post of hacking DB/DBP executables. Is it more safe
to use DLLs rather than DBP? "

DBP executables can't be hacked - it was an April Fool's Day joke. DBP executables are compiled to machine code - just like C++ is compiled to machine code.

DBClassic executables CAN (not easily) be hacked as DBC is an interpreter, but not DBPro ones cannot.

DBP exes are just as safe as DLLs.

Current Project: Retro Compo. Entry.
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th Apr 2003 20:13
More answers in sequence:

1 - More DLL's mean longer initialisation, so don't break them up too far.
3 - Wait a few more weeks for my C++ library - see my post on the C++ Library Update below.
4 - Absolutely not that would kill your performance.

Also, it would be better to use a TPC DLL rather than the DBClassic type, because this allows you access to the internal of DBPro. If you want to use my library, you *must* do it this way.
solo
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 11th Apr 2003 21:21
Thanks for the information.

MrTAToad:
The part you didn't understand (Question 3) refered to creating a string table, so the DBP could recognize user commands. I mentioned 'rc' that stands for "resource file".

Rob K:
forgive me if i'm wrong, but you've claimed some time before April Fool's , that you are able to hack DBP code, and you were supposed to make your hacking tool public. I remember you posted that Guy Savoie asked you not to publish it.

IanM:
Belive me, i'm waiting for your lib since you've posted your first screen shot/code example...
I remember you've said that there is a little overhead using that lib. Do you think that working with memblocks and DLLs should be slower than your lib performance?

[solo]

Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 11th Apr 2003 21:23
1. yes, but as toad says i'd keep similar functions to the same DLL as the more DLL the longer it takes to inilise and the larger you're final EXE will be.
however i'd also be sure to setup memory allocations using the TPC SDK and the Core Pointer

2. yes

3. setup the right structures to handle the data and this can be done very easily, a DLL i'm currently working on has that setup done within both the DLL and DBpro to get alot of information between them in the simplest fashion.
If you pass the memory ptr then load the data into a structure you can then use it however you choose - just have to make sure the C++ structure and the DB memory structure are the same (but thats kinda obvious )

4. as Ian said this'd kill performance, mostly because it take ALOT to load and unload DLLs in the memory due to thier setup ... instead if you take a look in you're F1 Help under Documents, you'll find the TPC SDK 1.1 which explains howto setup the functions for use in DBpro so you can use them as builtin functions rather than inexclusive functions

this doesn't mean they're no longer accessable using the old method of import/exporting data ... but it added better support and speed for the DLLs if setup like such.

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th Apr 2003 22:23
Actually Raven, TPC commands should be slightly faster than standard DLL calls for two reasons:
1) Function name lookup - it's done every time you use the CALL DLL command or function.
2) Indirect call through CALL DLL to the dll - you pay for that extra command call.

TPC commands (like the built-in commands) have their entry points identified at program startup once and then these are updated thoughout the executable. This is done automatically by the OS.

Solo - Memblocks and DLL calls from DBPro are much slower than direct memory allocation and normal function calls. And accessing the data in memory is massively faster in C than in DBPro. I will be providing memblock access, but that's only to allow you to access other data (meshes/images/sound etc).

My lib is as 'thin' a layer as I can make it and keep initialisation totally automatic. The overhead of this is only a few extra machine instructions per call to DBPro - 14 for the first call of each command, and 4 for any subsequent calls.
solo
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 11th Apr 2003 22:30
Raven:
I manage my structures exactly as you described.
Sure it's a very convenience way to deal an single/array of unit/s information.
Just be aware of virtual functions pointers that changes the data members offsets ( if you use virtual functions).

Does the TPC DLL loads each time i use builtin functions and when a function quits, delete it from memory? if so, maybe i should use the old method that let me control the loading/deleting DLL?

[solo]

MrTAToad
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 11th Apr 2003 22:44
No, I shouldn't think it is loaded before each call - it should get all the functions during compilation and leave it at that.

Good news everyone! I really am THAT good...
http://www.nickk.nildram.co.uk/ for great plug-ins - oh my, yes!
solo
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 11th Apr 2003 22:52
IanM,

My last comment was posted before i read your last one,
so you've answered my questions to Raven

I know that C is faster than DB, but do i have any choice
(unless your library is done and published) to use DLL and
memblocks to speed my program? The only reason i'm converting my program into C is to gain speed for data access.
I prefer the AI and math manipulations to be done in C++ rather than DB, and the only way i see, for now, is using memblocks+ptrs+DLLs.

Could you please explain in a few words how you access in your library to graphics DB internals, because i don't see how the global DB structure let you access most of the DB fields.

[solo]

IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th Apr 2003 23:45
Your choices depend on how many calls you will be making to your C code.

Once per sync, I would probably do things the way that you are.

Many (hundreds?) calls per sync (to synchronise value between DBPro and your DLL), I would start to consider either writing a TPC DLL, or using the '*' memory access operator (works just like in C) on memory allocated in a memblock or using 'make memory' - but the TPC method would be cleaner.

It's a bit of a sliding scale really. But if you want help optimising just give me a shout


As for disclosing how my lib does what it does:
1) All the information to do this yourself is available in the public domain, but...
2) It ain't easy to figure out - it's taken me 5 months to get this far (SDK Beta was released 2nd November).
3) I've discovered lots of gotchas and have had to refine what I've done several times - thank god I decided to automate as much as I have done. I expect to hit further problems before I complete it.
4) Some of the internals are too hard for me to figure out just yet, and some are just dangerous to the stability of the runtime.
solo
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 12th Apr 2003 00:44
IanM,
Thanks for the information and the help offer.
About the SDK, how do i get it? DBDN?

[solo]

IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 12th Apr 2003 01:21
Nope, you should find it in this location on your hard-drive:

C:\Program Files\Dark Basic Software\Dark Basic Professional\Help\documents\1 Third Party Commands.htm

If you need working Visual studio examples, look here:

http://www.matrix1.demon.co.uk/DBPro/TPCDLL.html
solo
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 12th Apr 2003 01:37
oh, that SDK... ok.

Login to post a reply

Server time is: 2026-07-11 09:30:27
Your offset time is: 2026-07-11 09:30:27