Best Practice: Long running setup function

<p>I have a list of ~2000 <a href="https://en.wikipedia.org/wiki/Chess_opening" rel="nofollow">chess openings</a> that I am initializing into a graph (positions as nodes, moves as edges) to speed up subsequent searches. Parsing the input file with moves represented in <a href="https://en.wikipedia.org/wiki/Portable_Game_Notation" rel="nofollow">PGN</a> is taking ~4 secs. Assuming I don&#39;t get this down to a reasonable time, what is the best way of exposing this via the API?</p> <p>The options I see are:</p> <ul> <li>have a &#34;Setup()&#34; function that must be called before use of API</li> <li>lazily call on the first search (I don&#39;t like this one)</li> <li>make setup private and call it in init()</li> </ul> <p>Im leaning toward the first one, but could anyone offer any guidance? </p> <p><a href="https://github.com/notnil/opening" rel="nofollow">opening package</a></p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><p>Do the first. Have the function return some value and only export the functionality through that value, to enforce the restriction that it has to be called before the API is used.</p></pre>loganjspears: <pre><p>I like it. That sounds like a winner. Thanks!</p></pre>ChristophBerger: <pre><p>Good approach. My first thought was to combine the first two options. That is, provide a setup method and if the client does not call ituntil the first search, then do the lazy init.</p></pre>TheMerovius: <pre><p>What is stuff is called concurrently? It&#39;s probably possible to do a search without synchronization, but suddenly you need it, to synchronize the initialization. Also, say you expose this to third parties via some API interface. You are not only holding up the <em>first</em> person to use it unacceptably long, but also everyone who calls it while the setup is in progress. Better to just answer with an error until the setup is done.</p> <p>I think lazy initialization is reasonable, but only if the initialization is fast enough that you&#39;d still give an answer in a reasonable time.</p></pre>go255: <pre><p>I think you should avoid lazy initialization completely and just force the implementer to call setup first before anything else. Unintended side effects are never a fun suprise and makes it harder to debug.</p> <p>Been one too many times when I&#39;ve wasted hours on some failed API call and realize it&#39;s just because it wasn&#39;t set up properly beforehand. That and not reading the docs completely...</p></pre>tty5: <pre><ol> <li><p>I would use a non-blocking (goroutine) version of 1 with a mutex - all requests would be on hold until the goroutine finishes, but program execution could continue. Often that would make even an unreasonable 4s open time invisible to end user.</p></li> <li><p>4 seconds sounds really, really, really slow. 2000 openings (~200KB of data) should be in low milliseconds range, even if the format is not very parse friendly.</p></li> </ol></pre>