![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Buffer size etc Topic Summary: Created On: 16-Feb-2005 17:34 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Confused about Buffers.
[1] Following code is executed in order. Buffer buf = create // [1a] Allocates no space? buf = "ABC" // [1b] finds space for 3 characters, points buffer, fill in with ABC? buf += "D" // [1c] finds space for 4 characters, points buffer, fills in with ABCD? length(buff, 10) // [1d] finds space for 10 characters, points buffer length 4, fills in with ABCD? length(buff, 3) // [1e] set length 3 but leaves 7 characters unused in the Buffer? tempStringOf(buf) // [1f] returns pointer to all 10 characters? stringOf(buf) // [1g] Returns string of 3 characters? setempty(buf) // [1h] retains 10 characters but sets length of buffer to zero? buf = "ABC" // [1i] sets length to 3; frees up 7 characters to memory? delete(buf) // [1j] frees up remaining characters. [2] My DXL gets slower and slower and I think its because memory is getting more and more fragmented due to the allocation and freeing up of buffer lenghts; and searching for free space takes longer and longer. I've also got some global buffers and some library function use; since global means I don't waste time creating and deleting them. I think I generally need the following: [2a] Routinely set the length of the buffer to some reasonably large value after creating it? [2b] When initializing a buffer, instead of "buf = InitVal" do "setempty(buf); buf += InitVal"? Anything else I need to consider? - Louie |
|
![]() |
|
![]() |
|
When buffers are created, they are allocated a size of 255, so small changes will not cause memory allocation/free operations.
Note that you can say Buffer b= create(1000) to give the buffer an initial size of 1000 characters. This would be the equivalent of your idea of setting the buffer to a large value after creating it, but simpler and faster. Buffers increase in size as required but do not decrease, even when set to empty. To reclaim the space used by a buffer, you can delete it. You could then set the buffer variable to another newly created buffer. Note that the process memory as seen in, say, the Windows task manager, may not immediately drop by the size of the buffer, since the system may allocate its own memory cache for the process. Judith |
|
![]() |
|
![]() |
|
Looks good; missed the create(size) option.
You seem to suggest: setting the buffer to an empty string does NOT free up space. So these two are equivalent: [1] buf = "" [2] setempty(buf) ?? Does setting the "length" of a buffer actually free up the space, or just mark the end of the string therein? You also seem to suggest that liberal use of "+=" additions will cause memory reallocation. Can I presume to suspect that the old buffer location is marked free but also fragmented? So not only will these += operations cause immediate loss of time, they also slow down future operations since memory is fragmented? All this suggest I should create buffers at the largest size that I'd reasonably use. I notice loss of time creating and deleting. For functions that use temporary buffers (usually create, calculate, delete), I'm VERY tempted to create a global buffer outside the function that only that function uses. The first thing the function does is setempty(buff), then calculates, then leaves the buffer. That leaves these residual buffers around and that's OK so long as [1] the function isn't recursive, and [2] this residual buffer space IS released when the DXL ends (or dialog is closed). I also noticed that if I insert a null character (char cNull = null; buff += cNull) into a buffer, that subsequent "stringOf" operations stop at the null character. I seem to recall something about that way back in "Advanced Abacus 401"... Anyway, I managed to bring this DXLs time down from about 5 hours to 25 minutes. - Louie |
|
![]() |
|
![]() |
|
Yes, buf = "" and setempty(buf) are functionally equivalent. setempty might be a tiny bit faster.
Setting the length of the buffer doesn't actually free up space. Yes, if you're building up a buffer with a lot of += operations, and the buffer isn't already big enough for the result, you will end up periodically reallocating. This allocates a new, larger space, copies the contents, and frees the old space. Whether or not fragmentation occurs is up to the operating system, but it's perfectly possible. Creating pretty large buffers at the outset seems like a good strategy to me. Your global temp buffer idea should work if you're careful about its use (e.g. in the midst of calculating, you don't end up calling a helper function which also uses the temp buffer). But sometimes it is worth doing something a bit dangerous for the sake of speed - 5 hours to 25 minutes sounds worth it. And you're right, the underlying string in a buffer is null-terminated, just like good old C. Judith |
|
![]() |
|
![]() |
|
Louie -- you seem to be convince the issue is a buffer problem --
Could your dxl be inhanced by adding a function that will close any module that is open in the background that is not immediately needed by your script. Closing modules will recover memory. |
|
![]() |
|
![]() |
|
Louie -- you seem to be convince the issue is a buffer problem --
Could your dxl be inhanced by adding a function that will close any module that is open in the background that is not immediately needed by your script. Closing modules will recover memory. |
|
![]() |
|
![]() |
|
Yup, have checked for open invisible modules and that's not it.
|
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Buffer size etc
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.