<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
<div>Hi, there.</div><div><br></div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Who cares if shout takes 0.15 or 0.148 seconds to style a text?</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px;line-height: 19.5px">Given that an entire Morphic cycle should take less than 16 milliseconds for the sake of responsiveness, such a difference would matter very much. Luckily, in my image, Shout is way faster to style the average piece of source code. :-) For about 400 characters it takes 192 microseconds. Thinking of slower systems, "nano" would be better to not be so close to "milli". ;-)</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px;line-height: 19.5px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px;line-height: 19.5px">Best,</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px;line-height: 19.5px">Marcel</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 20.07.2019 01:12:25 schrieb Tobias Pape <das.linux@gmx.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Levente :)<br><br><br>Thanks for bearing with me here..<br><br><br>> On 20.07.2019, at 00:49, Levente Uzonyi <leves@caesar.elte.hu> wrote:<br>> <br>> On Fri, 19 Jul 2019, Tobias Pape wrote:<br>> <br>>> <br>>>> On 19.07.2019, at 15:54, Levente Uzonyi <leves@caesar.elte.hu> wrote:<br>>>> Hi Tobias,<br>>>>>> […]<br>>>>> Could you tell me the use case here?<br>>>> ShoutCore-ul.66 in the Inbox.<br>>> <br>>> I see. I'd rather have Shout to make sure the index is valid _before_ accessing the string.<br>>> at:ifAbsent: is more concise and still idiomatic. It the out-of-range access a frequent case?<br>> <br>> Did you notice that I replaced #at:ifAbsent: sends with #atOrNil: sends there?<br><br>Yes, and I wanted to convey that I disagree.<br><br>> <br>> Why does it matter what the frequency of the out-of-range access case is?<br><br>Because optimizing it only makes sense if it is very frequent.<br><br>> <br>>> If so, we should really tackle _that_ instead of making pouring out nils fast.<br>> <br>> What's wrong with nil here?<br><br>What does nil mean here? It is used to convey "position out of range" but this domain knowledge is lost with using nil.<br>I don't think we're this deep in system level programming to condone using nil.<br><br>I understand that it has been used that way here (and not only in Shout's parser), but I don't think it is a good idea to prolifererate.<br><br>> <br>>> <br>>>>> This sounds like a convoluted range check.<br>>>> Yes, it's a way to avoid the range check being done by the image.<br>>>>> I mean, yes it would be faster to do<br>>>>> knorz := 'foo'<br>>>>> index := 32<br>>>>> ^ knorz atOrNil: index<br>>>>> but I would rather see<br>>>>> knorz := 'foo'<br>>>>> index := 32<br>>>>> ^ index <= knorz="" size="" iftrue:="" [knorz="" at:=""><!--=--><br>>>> That's not enough. You have to check the other end of the range as well.<br>>>> And that's what this method tries to avoid.<br>>> <br>>> But its telling a different story.<br>> <br>> What story is that?<br>> <br><br>The method conveys "get something from me or a system-level thingything, whysoever".<br>Yes, "we" know it is an optimized range check but it is not discoverable by anyone not very used to the code base.<br><br>>> We're going pretty low-level there, and I frankly don't see the benefit. Why should performance be paramount?<br>> <br>> Performance is the benefit. You see it, but you don't think you need it.<br><br>We trade readability and understandability as well as simplicity for performance here. But we don't even know if we <br>need to be fast here. Who cares if shout takes 0.15 or 0.148 seconds to style a text? <br>I know Tim complained, and probably rightfully so.<br>But I am still not convinced that this trade-off will pay out…<br><br>> <br>>> <br>>> <br>>>>> or more robust even<br>>>>> knorz := 'foo'<br>>>>> index := 32<br>>>>> ^ knorz atPin: 32<br>>>> You want to be able to distinguish invalid input and correct input in most cases. With Shout that's mandatory, so #atPin: wouldn't work.<br>>> <br>>> Well, I don't know. Rinard says otherwise[1]. In most cases, you want some valid data when accessing some collection; atPin doest that quite well.<br>> <br>> So, how would you use #atPin: with Shout?<br><br>With shout? probably not at all. This was a more general comment.<br>We're introducing a public API here, and it should have benefit beyond shout.<br><br>> <br>>> <br>>> The case at hand seems just to indicate that writing parsers is boring and hard, and we probably shouldn't have 2 parsers (3, if your have refactorings installed) in the image, that all will disagree slightly and have different characteristics each.<br>> <br>> I'm sure many disagree with you on the boring part.<br><br>Yeah, I meant that in a metaphorical way. Everytime I deal with a parser, it's exciting in the beginning and daunting in the long run…<br><br>> (IIRC the parser in Pharo replaced all three of those, but its performance is still worse than Parser's. I remember seeing numbers around 3x slower, but that may have changed).<br><br>I'm aware of the parser there. I have no performance infos at hand. <br>What I was hinting at was that if we optimize one Parser, and not the others, what's the overall benefit? We just end up with differently mysterious pieces of code.<br>But that's a different thread :)<br><br>> <br>>> <br>>> It's cool to make shout faster, however, we shouldn't introduce easy-to-misuse low-level API for that.<br>> <br>> I take that (and the rest of your mail) as a -1 from you for #atOrNil:.<br>> <br><br>more like a -0.5. I am amazed this works and has the performance implications you told, so I wrote all this to see whether I can convince myself of a +1 but didn't<br><br>Best regards<br> -Tobias<br><br>PS:<br><br>What about<br><br>at: aNumber orOffLimitSentinel: anObject<br> <primitive: 63=""><br> ^ anObject<br><br>Or would the primitive bail?<br><br><br>> Levente<br>> <br>>> <br>>> Best regards<br>>> -Tobias :)<br>>> <br>>> <br>>> <br>>> [1]: https://people.csail.mit.edu/rinard/paper/osdi04.pdf<br>>>> Levente<br>>>>> (even though that changes the semantic)<br>>>>> So, can you tell me the use case here?<br>>>>> Best regards<br>>>>> -Tobias<br>>>>> PS: That said, I think using #at: for String in the first place will<br>>>>> bite us down the road, whether we want to change the String<br>>>>> representation at some point (ropes, immutables, values, ...) or just<br>>>>> because Unicode is hard: ('Lèon' at: 3) can surely yield $'̀ ', $e<br>>>>> or $'è'<br><br><br><br></primitive:></leves@caesar.elte.hu></leves@caesar.elte.hu></div></blockquote></div>