Tiki in real time - page 16

New comment
 
Colleagues, do bear in mind that Print outputs asynchronously with a limited output queue. If you have a fast/large number of them, you may miss Prints altogether.
 
Dmitriy Skub:
Colleagues, keep in mind that Print outputs asynchronously with limited output queue. If you have a fast/large number of them, you may skip Prints altogether.

If the buffer overflows, it is possible, but only the developers will tell you that. If they have flush() after each print and a sufficiently sized buffer, it is unlikely.

 
Yuriy Zaytsev:

If the buffer overflows, it is possible, but only the developers will tell you that. If they have flush() after each print and the buffer is big enough, it is unlikely.

The developers have already told you - you haven't been listening carefully))

Flush has nothing to do with it at all. It is used in file operations.

 
Dmitriy Skub:

The developers have already said - you haven't been listening carefully))

Flash has nothing to do with it - at all. It is used for file operations.

I don't think there were any developers in this thread. Maybe elsewhere they said they may skip prints, but damn it :-) I don't monitor everything they write on this forum.

Yes, and the example we are parsing in which the print is not skipped, but only has a 4 second difference. And clearly the tick is unset which came in OnTick and in OnBook, and the unset gives the impression that in OnBook it came later by 4 seconds.

p.s.

Flush() is low level and high level and can be set immediately after any output to disk - if resetting is needed. And it doesn't have to be for low level write operations.

I meant if there is anything to flush, it will be flushed from the buffers to the disk. After flush, it will flush to the disk exactly when it is not costly to do so.
 

By the way I think the developers spit on the loss of prints in favour of performance.

 
Yuriy Zaytsev:

By the way I think the developers spit on the loss of prints in favour of performance.

Loss of prints, indicates that the developer did not implement the queue.
Whether this is good or bad is debatable.

 
Roman:

Loss of prints, indicates that the developer did not implement the queue.
Whether this is good or bad is debatable.

I don't know, they'll know.

It would be nice to disable the hell out of logging in the tester in favour of speed, for example.

 
Roman:

The loss of the prints, suggests that the developer has not implemented the queue.
Whether this is good or bad is debatable.

This is only when outputting to the screen. In the file, all these prints are saved losslessly.
 
Dmitriy Skub:
This is only when outputting to the screen. All these prints are saved in the file without any loss.

I got it, I confused the print with the arrival of the tick.
Then it turns out that the Print function is to blame.
And maybe for tests, it is better to output the result to a file.

Really, print lags very much.
Here is a simple example to check this: print a decent loop,
and you can immediately see the print rendering speed and the time of the prints will be normal.
 
Dmitriy Skub:
This is only when displayed on the screen. All these prints are saved in the file without any loss.

Yeah? Well, that's fine then.

I mean, when you play in the tester, sometimes you don't need the prints in the file or on the screen at all, but you do need the speed.

1...91011121314151617181920212223...26
New comment