<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Well, I found pathological behavior with BaseList::remove</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Instrumenting it with a printf of num_entries & i after the for loop, running against a test pcap then summarizing with awk gives:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Count, num_entries, i</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">1 3583 3536<br>1 3584 3537<br>1 3623 3542<br>1 3624 3543<br>1 3628 3620<br>1 3629 3621<br>1 3636 3562<br>1 3636 3625<br>1 3637 3563<br>1 3637 3626<br>1 3644 3576<br>1 3644 3641<br>1 3645 3577<br>1 3645 3642<br>1 3647 3641<br>1 3648 3642<br>1 3650 3629<br>1 3651 3630<br>1 3658 3647<br>1 3659 3648<br>1 3663 3655<br>1 3664 3656<br>1 3673 3629<br>1 3674 3630<br>1 3697 3686<br>1 3698 3687<br>1 3981 3595<br>1 3982 3596<br>1 4372 3978<br>1 4373 3979<br>1 4374 3656<br>1 4374 4371<br>1 4375 3657<br>1 4375 4372<br>1 4554 4371<br>1 4555 4372<br>1 4571 4367<br>1 4571 4551<br>1 4572 4368<br>1 4572 4552<br>1 4968 4566<br>1 4969 4567<br>1 5058 4566<br>1 5059 4567<br>1 5160 4963<br>1 5161 4964<br>1 5258 5157<br>1 5259 5158<br>1 5342 4566<br>1 5343 4567<br>1 5353 5253<br>1 5354 5254<br>1 5356 3638<br>1 5356 5337<br>1 5356 5350<br>1 5356 5351<br>1 5356 5353<br>1 5357 3639<br>1 5357 5338<br>1 5357 5351<br>1 5357 5352<br>1 5357 5354<br>1 5367 5351<br>1 5368 5352<br>1 5369 4556<br>1 5370 4557<br>1 5374 3675<br>1 5374 5366<br>1 5375 3676<br>1 5375 5367<br>1 5379 3664<br>1 5379 5045<br>1 5380 3665<br>1 5380 5046<br>1 5384 3601<br>1 5385 3602<br>1 5386 5354<br>1 5387 5355<br>1 5392 5370<br>1 5393 5371<br>1 5404 5363<br>1 5404 5381<br>1 5405 5364<br>1 5405 5382<br>1 5408 5341<br>1 5408 5368<br>1 5408 5399<br>1 5409 5342<br>1 5409 5369<br>1 5409 5400<br>1 5413 5401<br>1 5413 5403<br>1 5414 5402<br>1 5414 5404<br>1 5416 5408<br>1 5417 5409<br>1 5429 5395<br>1 5430 5396<br>1 5439 5381<br>1 5439 5406<br>1 5440 5382<br>1 5440 5407<br>1 5460 5436<br>1 5461 5437<br>1 5463 5407<br>1 5464 5408<br>1 5465 5397<br>1 5465 5460<br>1 5466 5398<br>1 5466 5461<br>1 5474 5359<br>1 5474 5451<br>1 5474 5456<br>1 5474 5471<br>1 5475 5360<br>1 5475 5452<br>1 5475 5457<br>1 5475 5472<br>1 5479 5456<br>1 5479 5476<br>1 5480 5457<br>1 5480 5477<br>1 5481 5416<br>1 5482 5417<br>1 5493 5426<br>1 5493 5474<br>1 5493 5488<br>1 5494 5427<br>1 5494 5475<br>1 5494 5489<br>1 5497 5357<br>1 5497 5367<br>1 5497 5461<br>1 5497 5462<br>1 5497 5480<br>1 5497 5488<br>1 5498 5358<br>1 5498 5368<br>1 5498 5462<br>1 5498 5463<br>1 5498 5481<br>1 5498 5489<br>1 5499 3682<br>1 5499 5460<br>1 5499 5476<br>1 5499 5478<br>1 5499 5480<br>1 5500 3683<br>1 5500 5461<br>1 5500 5477<br>1 5500 5479<br>1 5500 5481<br>2 3612 3609<br>2 3613 3610<br>2 3689 3686<br>2 3690 3687<br>2 3697 3694<br>2 3698 3695<br>2 5374 5371<br>2 5375 5372<br>2 5384 5381<br>2 5385 5382<br>2 5463 5460<br>2 5464 5461<br>2 5493 5465<br>2 5494 5466<br>2 5497 5484<br>2 5498 5485<br>2 5499 5482<br>2 5499 5488<br>2 5499 5490<br>2 5499 5492<br>2 5499 5494<br>2 5500 5483<br>2 5500 5489<br>2 5500 5491<br>2 5500 5493<br>2 5500 5495<br>3 4571 4568<br>3 4572 4569<br>3 5493 5490<br>3 5494 5491<br>3 5497 5490<br>3 5497 5492<br>3 5498 5491<br>3 5498 5493<br>3 5499 5486<br>3 5500 5487<br>4 3647 3644<br>4 3648 3645<br>5 5379 5376<br>5 5380 5377<br>7 5499 5496<br>7 5500 5497<br>10 5497 5494<br>10 5498 5495<br>26 3 2<br>5861 3 1<br>13714 4 4<br>14130 4 1<br>34914 4 0<br>74299 3 3<br>1518194 2 1<br>2648755 2 2<br>8166358 3 0<br>13019625 2 0<br>62953139 0 0<br>71512938 1 1<br>104294506 1 0</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">there are 286 instances where the list has over 3000 entries, and the desired entry is near the end... That linear search has got to be killing performance, even though its uncommon :-(</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The case of num_entries being 0 can be optimized a bit, but is relatively minor.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Now, I'll see if I can identify the offending List</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Jim</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 9, 2017 at 1:03 PM, Clark, Gilbert <span dir="ltr"><<a href="mailto:gc355804@ohio.edu" target="_blank">gc355804@ohio.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div id="m_-4595526810972472503divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
<p></p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
If you look in one of the subdirectories or another, in ages past there was a little shell script to incrementally execute bro against a specific trace, loading one script at a time to see the effect each of them had on the overall runtime. I can't remember
what it was called offhand, but it was useful for quick and dirty testing.</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
And yes, function calls in bro script land are pretty horrific in terms of overhead. Line per line, bro script in general isn't terribly efficient just because it doesn't do any of the things a modern interpreter might (e.g. just-in-time compilation). That's
not a criticism, it's only a note - most folks rely on horizontal scaling to deal with faster ingress, which I think makes a whole lot of sense.</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
Just in the event it's useful, I've attached some profiling I did on the script function overhead with the crap I wrote: these are some graphs on which script functions call which other script functions, how many times that happens, and how much time is spent
in each function. </p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
avggraph is the average time spent per-call, and resgraph is the aggregate time spent in each function across the entire run. The numbers' formatting needed some fixing, but never made it that far ...</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
I know Robin et. al. were working on different approaches for next-generation scripting kind of stuff, but haven't kept up well enough to really know where those are.</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
One thing I played around with was using plugin hooks to integrate other scripting languages into the bro fast path (luajit was my weapon of choice) and seeing if conversion from bro script to one of those other languages might improve the run time. Other
languages would still be less efficient than C, and anything garbage collected would need to be *really* carefully used, but ... it struck me as an idea that might be worth a look :)</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
And yeah, generally speaking, most of the toolkits I've played with for software-based packet processing absolutely do use memory pools for the fast path. They also use burst fetch tricks (to amortize the cost of fetching packets over X packets, rather than
fetching one packet at a time), and I've also seen quite a bit of prefetch / SIMD to try to keep things moving quickly once the packets make it to the CPU. </p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
Things start to get pretty crazy as packet rates increase, though: once you hit about 10 - 15 Gbps, even a *cache miss* on a modern system is enough to force a drop ...</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
For what it's worth ...</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<span style="font-size:12pt"></span></p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
-Gilbert</p>
<div dir="ltr">
<div id="m_-4595526810972472503x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p></p>
<p><br>
</p>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_-4595526810972472503x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Azoff, Justin S <<a href="mailto:jazoff@illinois.edu" target="_blank">jazoff@illinois.edu</a>><br>
<b>Sent:</b> Monday, October 9, 2017 10:19:26 AM<br>
<b>To:</b> Jim Mellander<br>
<b>Cc:</b> Clark, Gilbert; <a href="mailto:bro-dev@bro.org" target="_blank">bro-dev@bro.org</a><br>
<b>Subject:</b> Re: [Bro-Dev] Performance Enhancements</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div class="m_-4595526810972472503PlainText"><span class=""><br>
> On Oct 6, 2017, at 5:59 PM, Jim Mellander <<a href="mailto:jmellander@lbl.gov" target="_blank">jmellander@lbl.gov</a>> wrote:<br>
> <br>
> I particularly like the idea of an allocation pool that per-packet information can be stored, and reused by the next packet.<br>
<br>
Turns out bro does this most of the time.. unless you use the next_packet event. Normal connections use the sessions cache which holds connection objects, but new_packet has its own code path that creates the ip header from scratch for each packet. I tried
to pre-allocate PortVal objects, but I think I was screwing something up with 'Ref' and bro would just segfault on the 2nd connection.<br>
<br>
<br>
> There also are probably some optimizations of frequent operations now that we're in a 64-bit world that could prove useful - the one's complement checksum calculation in net_util.cc is one that comes to mind, especially since it works effectively a byte at
a time (and works with even byte counts only). Seeing as this is done per-packet on all tcp payload, optimizing this seems reasonable. Here's a discussion of do the checksum calc in 64-bit arithmetic:
<a href="https://locklessinc.com/articles/tcp_checksum/" id="m_-4595526810972472503LPlnk460696" target="_blank">
https://locklessinc.com/<wbr>articles/tcp_checksum/</a> - this website also has an x64 allocator that is claimed to be faster than tcmalloc, see:
<a href="https://locklessinc.com/benchmarks_allocator.shtml" id="m_-4595526810972472503LPlnk573572" target="_blank">
https://locklessinc.com/<wbr>benchmarks_allocator.shtml</a> (note: I haven't tried anything from this source, but find it interesting).
</span><div id="m_-4595526810972472503LPBorder_GT_15075788618480.7139535751653556" style="margin-bottom:20px;overflow:auto;width:100%;text-indent:0px">
<table id="m_-4595526810972472503LPContainer_15075788618460.023011669239466848" style="width:90%;background-color:rgb(255,255,255);overflow:auto;padding-top:20px;padding-bottom:20px;margin-top:20px;border-top:1px dotted rgb(200,200,200);border-bottom:1px dotted rgb(200,200,200)" cellspacing="0">
<tbody>
<tr style="border-spacing:0px" valign="top">
<td id="m_-4595526810972472503TextCell_15075788618470.7402341281523757" colspan="2" style="vertical-align:top;padding:0px;display:table-cell">
<div id="m_-4595526810972472503LPRemovePreviewContainer_15075788618470.5123370641558878"></div>
<div id="m_-4595526810972472503LPTitle_15075788618470.3171899875994839" style="color:rgb(51,51,51);font-weight:normal;font-size:21px;font-family:wf_segoe-ui_light,"Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;line-height:21px">
<a id="m_-4595526810972472503LPUrlAnchor_15075788618470.2987069461754146" href="https://locklessinc.com/articles/tcp_checksum/" style="text-decoration:none" target="_blank">The TCP/IP Checksum - Lockless Inc</a></div>
<div id="m_-4595526810972472503LPMetadata_15075788618470.09863541880680549" style="margin:10px 0px 16px;color:rgb(102,102,102);font-weight:normal;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:14px;line-height:14px">
<a href="http://locklessinc.com" target="_blank">locklessinc.com</a></div>
<div id="m_-4595526810972472503LPDescription_15075788618480.06801255594801758" style="display:block;color:rgb(102,102,102);font-weight:normal;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:14px;line-height:20px;max-height:100px;overflow:hidden">
The above obvious algorithm handles 16-bits at a time. Usually, if you process more data at a time, then performance is better. Since we have a 64-bit machine, we ...</div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<div id="m_-4595526810972472503LPBorder_GT_15075788618320.36056973346368304" style="margin-bottom:20px;overflow:auto;width:100%;text-indent:0px">
<table id="m_-4595526810972472503LPContainer_15075788618290.806994035485036" style="width:90%;background-color:rgb(255,255,255);overflow:auto;padding-top:20px;padding-bottom:20px;margin-top:20px;border-top:1px dotted rgb(200,200,200);border-bottom:1px dotted rgb(200,200,200)" cellspacing="0">
<tbody>
<tr style="border-spacing:0px" valign="top">
<td id="m_-4595526810972472503TextCell_15075788618300.5169792981041701" colspan="2" style="vertical-align:top;padding:0px;display:table-cell">
<div id="m_-4595526810972472503LPRemovePreviewContainer_15075788618300.4238627267153652"></div>
<div id="m_-4595526810972472503LPTitle_15075788618300.10657248543802322" style="color:rgb(51,51,51);font-weight:normal;font-size:21px;font-family:wf_segoe-ui_light,"Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;line-height:21px">
<a id="m_-4595526810972472503LPUrlAnchor_15075788618310.34685285951483835" href="https://locklessinc.com/benchmarks_allocator.shtml" style="text-decoration:none" target="_blank">Benchmarks of the Lockless Memory Allocator</a></div>
<div id="m_-4595526810972472503LPMetadata_15075788618310.2626417907254013" style="margin:10px 0px 16px;color:rgb(102,102,102);font-weight:normal;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:14px;line-height:14px">
<a href="http://locklessinc.com" target="_blank">locklessinc.com</a></div>
<div id="m_-4595526810972472503LPDescription_15075788618310.7408604877832383" style="display:block;color:rgb(102,102,102);font-weight:normal;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:14px;line-height:20px;max-height:100px;overflow:hidden">
The speed of various memory allocators is compared.</div>
</td>
</tr>
</tbody>
</table>
</div><span class="">
<br>
<br>
<br>
I couldn't get this code to return the right checksums inside bro (some casting issue?), but if it is faster it should increase performance by a small percentage. Comparing 'bro -b' runs on a pcap with 'bro -b -C' runs (which should show what kind of performance
increase we would get if that function took 0s to run) shows a decent chunk of time taken computing checksums.<br>
<br>
> I'm guessing there are a number of such "small" optimizations that could provide significant performance gains.<br>
<br>
I've been trying to figure out the best way to profile bro. So far attempting to use linux perf, or google perftools hasn't been able to shed much light on anything. I think the approach I was using to benchmark certain operations in the bro language is the
better approach.<br>
<br>
Instead of running bro and trying to profile it to figure out what is causing the most load, simply compare the execution of two bro runs with slightly different scripts/settings. I think this will end up being the better approach because it answers real questions
like "If I load this script or change this setting what is the performance impact on the bro process". When I did this last I used this method to compare the performance from one bro commit to the next, but I never tried comparing bro with one set of scripts
loaded to bro with a different set of scripts loaded.<br>
<br>
For example, the simplest and most dramatic test I came up with so far:<br>
<br>
$ time bro -r 2009-M57-day11-18.trace -b<br>
real 0m2.434s<br>
user 0m2.236s<br>
sys 0m0.200s<br>
<br>
$ cat np.bro<br>
event new_packet(c: connection, p: pkt_hdr)<br>
{<br>
<br>
}<br>
<br>
$ time bro -r 2009-M57-day11-18.trace -b np.bro<br>
real 0m10.588s<br>
user 0m10.392s<br>
sys 0m0.204s<br>
<br>
We've been saying for a while that adding that event is expensive, but I don't know if it's even been quantified.<br>
<br>
The main thing I still need to figure out is how to do this type of test in a cluster environment while replaying a long pcap.<br>
<br>
<br>
<br>
Somewhat related, came across this presentation yesterday:<br>
<br>
<a href="https://www.youtube.com/watch?v=NH1Tta7purM&feature=youtu.be" id="m_-4595526810972472503LPlnk981600" target="_blank">https://www.youtube.com/watch?<wbr>v=NH1Tta7purM&feature=youtu.be</a>
</span><div id="m_-4595526810972472503LPBorder_BVTaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g:dj1OSDFUdGE3cHVyTSZmZWF0dXJlPXlvdXR1LmJl_15075788631320.6588631408782302" style="margin-bottom:20px;overflow:auto;width:100%;text-indent:0px">
<table id="m_-4595526810972472503LPContainer_15075788631290.7188501874989972" style="width:90%;background-color:rgb(255,255,255);overflow:auto;padding-top:20px;padding-bottom:20px;margin-top:20px;border-top:1px dotted rgb(200,200,200);border-bottom:1px dotted rgb(200,200,200)" cellspacing="0">
<tbody>
<tr style="border-spacing:0px" valign="top">
<td id="m_-4595526810972472503ImageCell_15075788631290.059744885940983705" colspan="1" style="width:250px;display:table-cell;padding-right:20px">
<div id="m_-4595526810972472503LPImageContainer_15075788631290.623694700174936" style="background-color:rgb(255,255,255);height:140px;margin:auto;display:table;width:250px">
<a id="m_-4595526810972472503LPImageAnchor_15075788631300.537973884641167" href="https://www.youtube.com/watch?v=NH1Tta7purM&feature=youtu.be" style="display:table-cell;text-align:center" target="_blank" class="playable"><img id="m_-4595526810972472503LPThumbnailImageID_15075788631300.6639767114162103" style="display:inline-block;max-width:250px;max-height:250px;height:140px;width:250px;border-width:0px;vertical-align:bottom" src="https://i.ytimg.com/vi/NH1Tta7purM/maxresdefault.jpg" height="140" width="250"></a></div>
</td>
<td id="m_-4595526810972472503TextCell_15075788631310.12552324748897115" colspan="2" style="vertical-align:top;padding:0px;display:table-cell"><span class="">
<div id="m_-4595526810972472503LPRemovePreviewContainer_15075788631310.43939567302267957"></div>
<div id="m_-4595526810972472503LPTitle_15075788631310.0377885465686445" style="color:rgb(51,51,51);font-weight:normal;font-size:21px;font-family:wf_segoe-ui_light,"Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;line-height:21px">
<a id="m_-4595526810972472503LPUrlAnchor_15075788631310.27719944222920945" href="https://www.youtube.com/watch?v=NH1Tta7purM&feature=youtu.be" style="text-decoration:none" target="_blank">CppCon 2017: Carl Cook “When a Microsecond Is an Eternity: High Performance Trading Systems
in C++”</a></div>
</span><div id="m_-4595526810972472503LPMetadata_15075788631310.27916396341146066" style="margin:10px 0px 16px;color:rgb(102,102,102);font-weight:normal;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:14px;line-height:14px">
<a href="http://www.youtube.com" target="_blank">www.youtube.com</a></div>
<div id="m_-4595526810972472503LPDescription_15075788631310.5862619370408413" style="display:block;color:rgb(102,102,102);font-weight:normal;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:14px;line-height:20px;max-height:100px;overflow:hidden">
<a href="http://CppCon.org" target="_blank">http://CppCon.org</a> — Presentation Slides, PDFs, Source Code and other presenter materials are available at: <a href="https://github.com/CppCon/CppCon2017" target="_blank">https://github.com/CppCon/<wbr>CppCon2017</a> — Automated t...</div>
</td>
</tr>
</tbody>
</table>
</div><span class="">
<br>
<br>
<br>
CppCon 2017: Carl Cook “When a Microsecond Is an Eternity: High Performance Trading Systems in C++”<br>
<br>
Among other things, he mentions using a memory pool for objects instead of creating/deleting them.<br>
<br>
<br>
<br>
— <br>
Justin Azoff<br>
<br>
</span></div>
</span></font></div>
</div>
</blockquote></div><br></div>